Subject: bug#25975: Use HTTPS in `guix pull`

From: [email-masked] (Ludovic Courtès)
Date: Thu, 09 Mar 2017 17:11:44 +0100

Marius Bakke <[email-masked]> skribis:

> Ludovic Courtès <[email-masked]> writes:
>
>>> Simply propagate "gnutls" with "guix"?  The %load-path trick was
>>> stolen from (guix download), so I assumed it was safe ;-)
>>
>> The gexp in (guix download) that does that is a different story: it’s a
>> situation where we spawn a new process and we know which Guile and which
>> GnuTLS package is being used, so it’s completely safe.
>
> Ok, thanks for the clarification. Can we do the same in "pull"?

No, but we don’t have to: just assume GnuTLS is available and use the
https URL unconditionally.

We’ll update configure.ac and the manual to mention that GnuTLS is now a
requirement.

Sounds good?

>>>> It’s also a case where I think we might want to use the
>>>> already-installed certificates.
>>>
>>> If the URL is not from savannah, the GnuTLS defaults will be used (which
>>> should consult SSL_CERT_DIR). Or did you mean instead of "le-certs"?
>>
>> Yes, I was talking about le-certs.
>
> I have a strong preference for "hard coding" le-certs here. If the user
> don't have certs in their profile, they would have to both install some
> *and* configure the SSL_CERT_DIR variable before `guix pull` works.
>
> Using "le-certs" instead of one of the "kitchen sink" trust stores such
> as "nss-certs" also provides strong guarantees against MITM attacks even
> from state-level actors due to the certificate transparency program.
>
> LE's signing certificate expires in 2021 and the root in 2035, so it's
> not a huge maintenance overhead.

OK, that makes sense to me.  So you can add a ‘build-derivations’ call
for this package and that should be enough.

Or we could just as well ship the LE certificate instead of having a
package that downloads it etc.?

Thank you!

Ludo’.