Cuirass requires TLS certificates

  • Done
  • quality assurance status badge
Details
4 participants
  • Andreas Enge
  • Ludovic Courtès
  • Maxime Devos
  • zimoun
Owner
unassigned
Submitted by
Andreas Enge
Severity
normal
A
A
Andreas Enge wrote on 26 Feb 2018 21:51
(address . bug-guix@gnu.org)
20180226205158.GA2432@jurong
Hello,

the cuirass service requires TLS certificates to do continuous integration
of guix (or more generally, git repositories served over https). This works
when nss-certs is installed as a global package in the system.

Should the service depend on the nss-certs package? Or maybe take as an
optional configuration parameter a certificate package?

Andreas
L
L
Ludovic Courtès wrote on 27 Feb 2018 17:00
(name . Andreas Enge)(address . andreas@enge.fr)(address . 30619@debbugs.gnu.org)
87lgfe1kyf.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (7 lines)
> the cuirass service requires TLS certificates to do continuous integration
> of guix (or more generally, git repositories served over https). This works
> when nss-certs is installed as a global package in the system.
>
> Should the service depend on the nss-certs package? Or maybe take as an
> optional configuration parameter a certificate package?

I thought that, instead of assuming /etc/ssl/certs exists, the Cuirass
service could use (file-append nss-certs "/etc/ssl/certs/ca-certificates.crt").
That would make it self-contained.

That’s currently not possible though because this certificate bundle is
built as a profile hook. We would first need to export the procedure
that creates bundles, possibly by moving it to a new (guix
x509-certificates) module.

Thoughts?

Ludo’.
Z
Z
zimoun wrote on 16 Sep 2021 09:33
8635q5rn44.fsf@gmail.com
Hi,

On Tue, 27 Feb 2018 at 17:00, ludo@gnu.org (Ludovic Courtès) wrote:
Toggle quote (18 lines)
> Andreas Enge <andreas@enge.fr> skribis:
>
>> the cuirass service requires TLS certificates to do continuous integration
>> of guix (or more generally, git repositories served over https). This works
>> when nss-certs is installed as a global package in the system.
>>
>> Should the service depend on the nss-certs package? Or maybe take as an
>> optional configuration parameter a certificate package?
>
> I thought that, instead of assuming /etc/ssl/certs exists, the Cuirass
> service could use (file-append nss-certs "/etc/ssl/certs/ca-certificates.crt").
> That would make it self-contained.
>
> That’s currently not possible though because this certificate bundle is
> built as a profile hook. We would first need to export the procedure
> that creates bundles, possibly by moving it to a new (guix
> x509-certificates) module.

What is the status of this old bug [1]? Well, if it is not fixed yet,
it seems a forgotten bug. :-)


Cheers,
simon
Z
Z
zimoun wrote on 12 Oct 2021 23:57
(name . Ludovic Courtès)(address . ludo@gnu.org)
86ily1kitk.fsf@gmail.com
Hi,

On Thu, 16 Sep 2021 at 09:33, zimoun <zimon.toutoune@gmail.com> wrote:
Toggle quote (24 lines)
> On Tue, 27 Feb 2018 at 17:00, ludo@gnu.org (Ludovic Courtès) wrote:
>> Andreas Enge <andreas@enge.fr> skribis:
>>
>>> the cuirass service requires TLS certificates to do continuous integration
>>> of guix (or more generally, git repositories served over https). This works
>>> when nss-certs is installed as a global package in the system.
>>>
>>> Should the service depend on the nss-certs package? Or maybe take as an
>>> optional configuration parameter a certificate package?
>>
>> I thought that, instead of assuming /etc/ssl/certs exists, the Cuirass
>> service could use (file-append nss-certs "/etc/ssl/certs/ca-certificates.crt").
>> That would make it self-contained.
>>
>> That’s currently not possible though because this certificate bundle is
>> built as a profile hook. We would first need to export the procedure
>> that creates bundles, possibly by moving it to a new (guix
>> x509-certificates) module.
>
> What is the status of this old bug [1]? Well, if it is not fixed yet,
> it seems a forgotten bug. :-)
>
> 1: <http://issues.guix.gnu.org/issue/30619>

From my understanding, this old bug could be closed. But I am not sure
to get it right about this TLS story. So closing?


Cheers,
simon
L
L
Ludovic Courtès wrote on 15 Oct 2021 17:20
(name . zimoun)(address . zimon.toutoune@gmail.com)
87o87qiaau.fsf@gnu.org
Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (28 lines)
> On Thu, 16 Sep 2021 at 09:33, zimoun <zimon.toutoune@gmail.com> wrote:
>> On Tue, 27 Feb 2018 at 17:00, ludo@gnu.org (Ludovic Courtès) wrote:
>>> Andreas Enge <andreas@enge.fr> skribis:
>>>
>>>> the cuirass service requires TLS certificates to do continuous integration
>>>> of guix (or more generally, git repositories served over https). This works
>>>> when nss-certs is installed as a global package in the system.
>>>>
>>>> Should the service depend on the nss-certs package? Or maybe take as an
>>>> optional configuration parameter a certificate package?
>>>
>>> I thought that, instead of assuming /etc/ssl/certs exists, the Cuirass
>>> service could use (file-append nss-certs "/etc/ssl/certs/ca-certificates.crt").
>>> That would make it self-contained.
>>>
>>> That’s currently not possible though because this certificate bundle is
>>> built as a profile hook. We would first need to export the procedure
>>> that creates bundles, possibly by moving it to a new (guix
>>> x509-certificates) module.
>>
>> What is the status of this old bug [1]? Well, if it is not fixed yet,
>> it seems a forgotten bug. :-)
>>
>> 1: <http://issues.guix.gnu.org/issue/30619>
>
> From my understanding, this old bug could be closed. But I am not sure
> to get it right about this TLS story. So closing?

The Cuirass Shepherd service still does:

#:environment-variables
(list "GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt" …)

which means that users still need to install certificates globally.

Now, whether it’s an issue, I don’t know.

Maybe we can close?

Thanks,
Ludo’.
Z
Z
zimoun wrote on 26 Nov 2021 02:38
(name . Ludovic Courtès)(address . ludo@gnu.org)
86k0gvr90x.fsf@gmail.com
Hi,

On Fri, 15 Oct 2021 at 17:20, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (15 lines)
> zimoun <zimon.toutoune@gmail.com> skribis:
>> On Thu, 16 Sep 2021 at 09:33, zimoun <zimon.toutoune@gmail.com> wrote:
>>> On Tue, 27 Feb 2018 at 17:00, ludo@gnu.org (Ludovic Courtès) wrote:

> The Cuirass Shepherd service still does:
>
> #:environment-variables
> (list "GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt" …)
>
> which means that users still need to install certificates globally.
>
> Now, whether it’s an issue, I don’t know.
>
> Maybe we can close?

I propose to close since I do not see what could the next action.



Cheers,
simon
M
M
Maxime Devos wrote on 26 Nov 2021 07:28
72886a55a3351fb56335c71179bdf155e27a630a.camel@telenet.be
zimoun schreef op vr 26-11-2021 om 02:38 [+0100]:
Toggle quote (25 lines)
> Hi,
>
> On Fri, 15 Oct 2021 at 17:20, Ludovic Courtès <ludo@gnu.org> wrote:
> > zimoun <zimon.toutoune@gmail.com> skribis:
> > > On Thu, 16 Sep 2021 at 09:33, zimoun <zimon.toutoune@gmail.com>
> > > wrote:
> > > > On Tue, 27 Feb 2018 at 17:00, ludo@gnu.org (Ludovic Courtès)
> > > > wrote:
>
> > The Cuirass Shepherd service still does:
> >
> >               #:environment-variables
> >               (list "GIT_SSL_CAINFO=/etc/ssl/certs/ca-
> > certificates.crt" …)
> >
> > which means that users still need to install certificates globally.
> >
> > Now, whether it’s an issue, I don’t know.
> >
> > Maybe we can close?
>
> I propose to close since I do not see what could the next action.
>
> 1: <http://issues.guix.gnu.org/issue/30619>

The next action would be splitting of the bundle generation from the
profile code, and adding a ‘certificates’ field defaulting to nss-
certs, as Ludo seemed to suggest.

This could be useful if the server the channel repositories are on use
self-signed certificates (are git repositories of channels over https
the reason cuirass requires TLS certificates).


Greetings,
Maxime
M
M
Maxime Devos wrote on 26 Nov 2021 07:31
3cdff52c716f48634eb81cb00884dca3c3a4fece.camel@telenet.be
Maxime Devos schreef op vr 26-11-2021 om 06:28 [+0000]:
Toggle quote (6 lines)
> [...]
> This could be useful if the server the channel repositories are on
> use
> self-signed certificates (are git repositories of channels over https
> the reason cuirass requires TLS certificates).

This was meant to be:

‘This could be useful if the server the channel repositories are on
use self-signed certificates (are git repositories of channels over
https the reason cuirass requires TLS certificates?).’
M
M
Maxime Devos wrote on 26 Nov 2021 07:32
841474d35582bbe18dea7336a9149603ac4b8d82.camel@telenet.be
Maxime Devos schreef op vr 26-11-2021 om 06:28 [+0000]:
Toggle quote (5 lines)
> This could be useful if the server the channel repositories are on
> use
> self-signed certificates (are git repositories of channels over https
> the reason cuirass requires TLS certificates).

Oops, this argument doesn't have much value, because those certificates
might as well be added to the system profile.
Z
Z
zimoun wrote on 5 Jan 2022 00:09
(name . Maxime Devos)(address . maximedevos@telenet.be)
86r19nayjh.fsf@gmail.com
Hi Maxime.

On Fri, 26 Nov 2021 at 06:28, Maxime Devos <maximedevos@telenet.be> wrote:
Toggle quote (26 lines)
> zimoun schreef op vr 26-11-2021 om 02:38 [+0100]:
>> On Fri, 15 Oct 2021 at 17:20, Ludovic Courtès <ludo@gnu.org> wrote:
>> > zimoun <zimon.toutoune@gmail.com> skribis:
>> > > On Thu, 16 Sep 2021 at 09:33, zimoun <zimon.toutoune@gmail.com>
>> > > > On Tue, 27 Feb 2018 at 17:00, ludo@gnu.org (Ludovic Courtès)
>>
>> > The Cuirass Shepherd service still does:
>> >
>> >               #:environment-variables
>> >               (list "GIT_SSL_CAINFO=/etc/ssl/certs/ca-
>> > certificates.crt" …)
>> >
>> > which means that users still need to install certificates globally.
>> >
>> > Now, whether it’s an issue, I don’t know.
>> >
>> > Maybe we can close?
>>
>> I propose to close since I do not see what could the next action.
>>
>> 1: <http://issues.guix.gnu.org/issue/30619>
>
> The next action would be splitting of the bundle generation from the
> profile code, and adding a ‘certificates’ field defaulting to nss-
> certs, as Ludo seemed to suggest.

Do you have an idea how to implement this suggestion? Otherwise, I
think closing is reasonable. :-)

Cheers,
simon
M
M
Maxime Devos wrote on 5 Jan 2022 10:53
(name . zimoun)(address . zimon.toutoune@gmail.com)
61df0fdc1a0db3ec42f2a03500333b0a1bbaa2eb.camel@telenet.be
zimoun schreef op wo 05-01-2022 om 00:09 [+0100]:
Toggle quote (32 lines)
> Hi Maxime.
>
> On Fri, 26 Nov 2021 at 06:28, Maxime Devos <maximedevos@telenet.be> wrote:
> > zimoun schreef op vr 26-11-2021 om 02:38 [+0100]:
> > > On Fri, 15 Oct 2021 at 17:20, Ludovic Courtès <ludo@gnu.org> wrote:
> > > > zimoun <zimon.toutoune@gmail.com> skribis:
> > > > > On Thu, 16 Sep 2021 at 09:33, zimoun <zimon.toutoune@gmail.com>
> > > > > > On Tue, 27 Feb 2018 at 17:00, ludo@gnu.org (Ludovic Courtès)
> > >
> > > > The Cuirass Shepherd service still does:
> > > >
> > > >               #:environment-variables
> > > >               (list "GIT_SSL_CAINFO=/etc/ssl/certs/ca-
> > > > certificates.crt" …)
> > > >
> > > > which means that users still need to install certificates globally.
> > > >
> > > > Now, whether it’s an issue, I don’t know.
> > > >
> > > > Maybe we can close?
> > >
> > > I propose to close since I do not see what could the next action.
> > >
> > > 1: <http://issues.guix.gnu.org/issue/30619>
> >
> > The next action would be splitting of the bundle generation from the
> > profile code, and adding a ‘certificates’ field defaulting to nss-
> > certs, as Ludo seemed to suggest.
>
> Do you have an idea how to implement this suggestion? Otherwise, I
> think closing is reasonable. :-)

That suggestion (+ Ludovic's suggestion of a
(guix x509-certificates) module) was my suggested implementation, it
just needs to be translated from a description in English to an actual
patch .

Anyway, I don't think closing is reasonable, because the bug
(certificates need to be installed globally) still exist, and it
is actionable (there's even a suggested implementation,
so a sufficiently motivated party (not me currently) could address the
issue.

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYdVqkBccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7p2IAQDax1OyBEEBRaaH3SZAoEsF9nrm
pF+Tisf6dcWj4mRKTQD/YkE6I9WhushEQz9+RTPHOqM+e/yUL9rDNHz7T/kZkQA=
=Dlt+
-----END PGP SIGNATURE-----


M
M
Maxime Devos wrote on 21 Jan 2022 11:44
0f5d7f7984633b3fca6a732ec608f9a964d9fe1e.camel@telenet.be
bugs 30619 + donewontfix
thanks

Toggle quote (2 lines)
> [various discussion]

While I believe a 'certificates' field or the like would be nice,
there does not appear to be a need or interest, hence closing.

If someone would like to implement some solution or has a need,
they can reopen the bug (see

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYeqOehccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7vScAP4tFtz6D/pPDLzmuJfxGeKtyFYZ
YGH2SMiYFKizWa2qkgD/ZUz6h9Dh9UVRws2kMU+1y9niLQf6yQlqBiuIIbka8AE=
=XYYZ
-----END PGP SIGNATURE-----


Closed
?