Leo Famulari <leo@famulari.name> writes:

> On Tue, Feb 28, 2017 at 03:59:42PM +0100, Marius Bakke wrote:
>> For some reason setting SSL_CERT_FILE to "le-certs.pem" does not work
>> for `guix download`, but having just the one file in SSL_CERT_DIR does.
>> That's good enough for me! Could you make this into a Guix package? 
>
> I plan to make a package once these issues are resolved:
>
> 1) Which "trust path" should we use? The one using ISRG (the "native"
> Let's Encrypt root certificate authority), or the one that is
> cross-signed by IdenTrust? Or should we keep it as-is, where both are
> included? This is my first time creating a custom set of certificates,
> so I don't know all the issues.
>
> They recommend that server operators used the cross-signed trust chain
> because the ISRG trust chain is not yet widely deployed in web browsers,
> but that's not an issue for this use case.

I don't fully understand the differences here, but will do some reading.

> 2) I'd like at least two other Guix developers to try recreating the
> repository "from scratch", and to send signed email to this thread
> saying that they were able to successfully recreate this custom
> certificate store.

I will do this later.

>> I wonder what happens if we simply switch %snapshot-url to HTTPS in
>> `guix/scripts/pull.scm`. How many users do not have SSL_CERT_DIR
>> configured? I think it would be sufficient to mention in the manual to
>> install one of "nss-certs" or "le-certs" before running `guix pull` for
>> the first time. How does that sound?
>
> I think it's too much of a regression if users have to fiddle with
> environment variables for `guix pull` to work reliably. People are
> constantly asking for help with environment variables in the #guix chat
> room.
>
> I want to bundle a 'le-certs' package with GNU Guix, and change `guix
> pull` to know to use the le-certs bundle when pulling from
> %snapshot-url. For other URLs, users will have to take care of it
> themselves. 

This sounds like a better approach. Also, I did not see this email
before sending the patch! If you package it up, I can look into
realizing the package in `guix pull` directly.

> This should preserve the existing user experience of `guix pull`, which
> is that the default invocation "just works", at least in terms of
> downloading the source code. It could fail anyways if their clock is way
> off... any other ideas about how it could fail?

Not off the top of my head. But see the patch for a fallback
"--insecure" option if all else fails.

Thanks a lot for taking this on!