Re: `guix pull` over HTTPS

[Leo Famulari]

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.

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

> $ CURL_CA_BUNDLE=/tmp/le-certs/le-certs.pem curl -sv https://nrk.no > 
> /dev/null
> * Rebuilt URL to: https://nrk.no/
> *   Trying 160.68.205.231...
> * TCP_NODELAY set
> * Connected to nrk.no (160.68.205.231) port 443 (#0)
> * found 10 certificates in /tmp/le-certs/le-certs.pem
> * ALPN, offering http/1.1
> * SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
> * server certificate verification failed. CAfile: /tmp/le-certs/le-certs.pem 
> CRLfile: none
> * Closing connection 0
> 
> $ CURL_CA_BUNDLE=/tmp/le-certs/le-certs.pem curl -sv https://gnu.org > 
> /dev/null
> * Rebuilt URL to: https://gnu.org/
> *   Trying 208.118.235.148...
> * TCP_NODELAY set
> * Connected to gnu.org (208.118.235.148) port 443 (#0)
> * found 10 certificates in /tmp/le-certs/le-certs.pem
> * ALPN, offering http/1.1
> * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
> *        server certificate verification OK
> *        server certificate status verification SKIPPED
> *        common name: gnu.org (matched)
> *        server certificate expiration date OK
> *        server certificate activation date OK
> *        certificate public key: RSA
> *        certificate version: #3
> *        subject: CN=gnu.org
> *        start date: Wed, 15 Feb 2017 10:01:00 GMT
> *        expire date: Tue, 16 May 2017 10:01:00 GMT
> *        issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
> *        compression: NULL
> 
> $ GIT_SSL_CAINFO="" git clone --depth=1 
> https://git.savannah.gnu.org/git/guix.git
> Cloning into 'guix'...
> fatal: unable to access 'https://git.savannah.gnu.org/git/guix.git/': Problem 
> with the SSL CA cert(path? access rights?)
> 
> $ GIT_SSL_CAINFO=/tmp/le-certs/le-certs.pem git clone --depth=1 
> https://git.savannah.gnu.org/git/guix.git
> Cloning into 'guix'...
> remote: Counting objects: 1409, done.

Excellent :)

signature.asc
Description: PGP signature