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
?
Your comment

This issue is archived.

To comment on this conversation send an email to 30619@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 30619
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch