`guix pull` over HTTPS

`guix pull` over HTTPS

[Leo Famulari]

[-- Attachment #1.1: Type: text/plain, Size: 1301 bytes --]

Currently, the default source for `guix pull` is
<http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz>.

It's suboptimal to download the Guix source code over HTTP, since the
data can be mutated and recorded in transit. [0]

The Savannah admins have been working tirelessly to improve the Savannah
infrastructure, and they will soon announce the public availability of
Git served over HTTPS. [1]

HTTPS is not a security panacea but, in my opinion, we should use it if
it's available, at least until `guix pull` can verify commit signatures.

However, it's a little harder to get right than HTTP. For example, `guix
pull` could fail if there is a problem with the user's certificate
store, or if their clock is wrong.

Does anyone have any specific concerns or advice about changing the
value of %snapshot-url in (guix scripts pull) to use the HTTPS URL?
Should the change be that simple, or should we do more?

The attached patch works for me on a foreign distro when SSL_CERT_DIR
and SSL_CERT_FILE are set as described in the manual (section 7.2.9
X.509 Certificates) and GnuTLS-Guile is available in my environment.

[0] Discussion of the general problems with `guix pull`:
http://bugs.gnu.org/22883

[1]
http://lists.gnu.org/archive/html/savannah-hackers-public/2017-02/msg00034.html

[-- Attachment #1.2: 0001-pull-Download-GNU-Guix-with-HTTPS.patch --]
[-- Type: text/plain, Size: 859 bytes --]

From 63eca1a41d993c04d662736589872fbc7123a168 Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Thu, 9 Feb 2017 12:13:42 +0100
Subject: [PATCH] pull: Download GNU Guix with HTTPS.

* guix/scripts/pull.scm (%snapshot-url): Use HTTPS URL.
---
 guix/scripts/pull.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index 3f940f94d..2312eed29 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -45,7 +45,7 @@
 
 (define %snapshot-url
   ;; "http://hydra.gnu.org/job/guix/master/tarball/latest/download"
-  "http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
+  "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
   )
 
 (define-syntax-rule (with-environment-variable variable value body ...)
-- 
2.11.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: `guix pull` over HTTPS

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On Thu, Feb 09, 2017 at 04:55:12PM +0100, Leo Famulari wrote:
> Does anyone have any specific concerns or advice about changing the
> value of %snapshot-url in (guix scripts pull) to use the HTTPS URL?
> Should the change be that simple, or should we do more?

While testing, I realized that an X.509 certificate store is not a
standard feature of GuixSD, so using Savannah's HTTPS URL will not work
in all cases.

SSL_CERT_FILE and SSL_CERT_DIR appear to be set unconditionally in (gnu
system operating-system-environment-variables), so it's not enough to
test that they are set in order to decide which protocol to download the
Guix source code with.

Any advice on how to proceed?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Feb 09, 2017 at 04:55:12PM +0100, Leo Famulari wrote:
>> Does anyone have any specific concerns or advice about changing the
>> value of %snapshot-url in (guix scripts pull) to use the HTTPS URL?
>> Should the change be that simple, or should we do more?
>
> While testing, I realized that an X.509 certificate store is not a
> standard feature of GuixSD, so using Savannah's HTTPS URL will not work
> in all cases.
>
> SSL_CERT_FILE and SSL_CERT_DIR appear to be set unconditionally in (gnu
> system operating-system-environment-variables), so it's not enough to
> test that they are set in order to decide which protocol to download the
> Guix source code with.
>
> Any advice on how to proceed?

Initially, I didn’t want to have ‘nss-certs’ in ‘%base-packages’ or
anything like that, on the grounds that the whole X.509 CA story is
completely broken IMO.  I wonder if we should revisit that, on the
grounds that “it’s better than nothing.”

The next question is what to do with foreign distros, and whether we
should bundle ‘nss-certs’ in the binary tarball, which is not exciting.

Alternately we could have a package that provides only the Let’s Encrypt
certificate chain, if that’s what Savannah uses.

Thoughts?

Ludo’.

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Leo Famulari <leo@famulari.name> skribis:
>
>> On Thu, Feb 09, 2017 at 04:55:12PM +0100, Leo Famulari wrote:
>>> Does anyone have any specific concerns or advice about changing the
>>> value of %snapshot-url in (guix scripts pull) to use the HTTPS URL?
>>> Should the change be that simple, or should we do more?
>>
>> While testing, I realized that an X.509 certificate store is not a
>> standard feature of GuixSD, so using Savannah's HTTPS URL will not work
>> in all cases.
>>
>> SSL_CERT_FILE and SSL_CERT_DIR appear to be set unconditionally in (gnu
>> system operating-system-environment-variables), so it's not enough to
>> test that they are set in order to decide which protocol to download the
>> Guix source code with.
>>
>> Any advice on how to proceed?
>
> Initially, I didn’t want to have ‘nss-certs’ in ‘%base-packages’ or
> anything like that, on the grounds that the whole X.509 CA story is
> completely broken IMO.  I wonder if we should revisit that, on the
> grounds that “it’s better than nothing.”
>
> The next question is what to do with foreign distros, and whether we
> should bundle ‘nss-certs’ in the binary tarball, which is not exciting.
>
> Alternately we could have a package that provides only the Let’s Encrypt
> certificate chain, if that’s what Savannah uses.
>
> Thoughts?

If the private key used on https://git.savannah.gnu.org/ is static, one
option would be to "pin" the corresponding public key. However, some LE
clients also rotate the private key when renewing, so we'd need to ask
SV admins. And also receive notices in advance if the key ever changes.

Pinning the intermediate CAs might work, but what to do when the
certificate is signed by a new intermediate (which may happen[0])? How
to deliver updates to users with old certs?

See: https://www.owasp.org/index.php/Pinning_Cheat_Sheet and
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

..for quick and long introductions, respectively.

[0] https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625?source_topic_id=2450

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Leo Famulari <leo@famulari.name> skribis:
>>

[...]

>> Initially, I didn’t want to have ‘nss-certs’ in ‘%base-packages’ or
>> anything like that, on the grounds that the whole X.509 CA story is
>> completely broken IMO.  I wonder if we should revisit that, on the
>> grounds that “it’s better than nothing.”
>>
>> The next question is what to do with foreign distros, and whether we
>> should bundle ‘nss-certs’ in the binary tarball, which is not exciting.
>>
>> Alternately we could have a package that provides only the Let’s Encrypt
>> certificate chain, if that’s what Savannah uses.
>>
>> Thoughts?
>
> If the private key used on https://git.savannah.gnu.org/ is static, one
> option would be to "pin" the corresponding public key. However, some LE
> clients also rotate the private key when renewing, so we'd need to ask
> SV admins. And also receive notices in advance if the key ever changes.
>
> Pinning the intermediate CAs might work, but what to do when the
> certificate is signed by a new intermediate (which may happen[0])? How
> to deliver updates to users with old certs?
>
> See: https://www.owasp.org/index.php/Pinning_Cheat_Sheet and
> https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
>
> ..for quick and long introductions, respectively.
>
> [0] https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625?source_topic_id=2450

All good points.  Well, I guess there’s not much we can do?

Ludo’.

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Leo Famulari <leo@famulari.name> skribis:
>>>
>
> [...]
>
>>> Initially, I didn’t want to have ‘nss-certs’ in ‘%base-packages’ or
>>> anything like that, on the grounds that the whole X.509 CA story is
>>> completely broken IMO.  I wonder if we should revisit that, on the
>>> grounds that “it’s better than nothing.”
>>>
>>> The next question is what to do with foreign distros, and whether we
>>> should bundle ‘nss-certs’ in the binary tarball, which is not exciting.
>>>
>>> Alternately we could have a package that provides only the Let’s Encrypt
>>> certificate chain, if that’s what Savannah uses.
>>>
>>> Thoughts?
>>
>> If the private key used on https://git.savannah.gnu.org/ is static, one
>> option would be to "pin" the corresponding public key. However, some LE
>> clients also rotate the private key when renewing, so we'd need to ask
>> SV admins. And also receive notices in advance if the key ever changes.
>>
>> Pinning the intermediate CAs might work, but what to do when the
>> certificate is signed by a new intermediate (which may happen[0])? How
>> to deliver updates to users with old certs?
>>
>> See: https://www.owasp.org/index.php/Pinning_Cheat_Sheet and
>> https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
>>
>> ..for quick and long introductions, respectively.
>>
>> [0] https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625?source_topic_id=2450
>
> All good points.  Well, I guess there’s not much we can do?

I think pinning the public key could work, if the Savannah
administrators are aware of it. But we'd need a reliable fallback
mechanism in case the private key needs to be updated.

I think having a separate 'le-certs' package that can verify the Lets
Encrypt chain sounds like the easiest option. Presumably new
intermediates etc will be known well in advance.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: `guix pull` over HTTPS

[ng0]

On 17-02-10 23:43:45, Marius Bakke wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> > Marius Bakke <mbakke@fastmail.com> skribis:
> >
> >> Ludovic Courtès <ludo@gnu.org> writes:
> >>
> >>> Leo Famulari <leo@famulari.name> skribis:
> >>>
> >
> > [...]
> >
> >>> Initially, I didn’t want to have ‘nss-certs’ in ‘%base-packages’ or
> >>> anything like that, on the grounds that the whole X.509 CA story is
> >>> completely broken IMO.  I wonder if we should revisit that, on the
> >>> grounds that “it’s better than nothing.”
> >>>
> >>> The next question is what to do with foreign distros, and whether we
> >>> should bundle ‘nss-certs’ in the binary tarball, which is not exciting.
> >>>
> >>> Alternately we could have a package that provides only the Let’s Encrypt
> >>> certificate chain, if that’s what Savannah uses.
> >>>
> >>> Thoughts?
> >>
> >> If the private key used on https://git.savannah.gnu.org/ is static, one
> >> option would be to "pin" the corresponding public key. However, some LE
> >> clients also rotate the private key when renewing, so we'd need to ask
> >> SV admins. And also receive notices in advance if the key ever changes.
> >>
> >> Pinning the intermediate CAs might work, but what to do when the
> >> certificate is signed by a new intermediate (which may happen[0])? How
> >> to deliver updates to users with old certs?
> >>
> >> See: https://www.owasp.org/index.php/Pinning_Cheat_Sheet and
> >> https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
> >>
> >> ..for quick and long introductions, respectively.
> >>
> >> [0] https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625?source_topic_id=2450
> >
> > All good points.  Well, I guess there’s not much we can do?
> 
> I think pinning the public key could work, if the Savannah
> administrators are aware of it. But we'd need a reliable fallback
> mechanism in case the private key needs to be updated.
> 
> I think having a separate 'le-certs' package that can verify the Lets
> Encrypt chain sounds like the easiest option. Presumably new
> intermediates etc will be known well in advance.

I am relatively sure that LE would let its now very large user base know
in advance when a change like a new intermediate CA is being introduced,
but if we are really in doubt we could ask LE themselves.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Marius Bakke <mbakke@fastmail.com> skribis:

[...]

>>> If the private key used on https://git.savannah.gnu.org/ is static, one
>>> option would be to "pin" the corresponding public key. However, some LE
>>> clients also rotate the private key when renewing, so we'd need to ask
>>> SV admins. And also receive notices in advance if the key ever changes.
>>>
>>> Pinning the intermediate CAs might work, but what to do when the
>>> certificate is signed by a new intermediate (which may happen[0])? How
>>> to deliver updates to users with old certs?
>>>
>>> See: https://www.owasp.org/index.php/Pinning_Cheat_Sheet and
>>> https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
>>>
>>> ..for quick and long introductions, respectively.
>>>
>>> [0] https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625?source_topic_id=2450
>>
>> All good points.  Well, I guess there’s not much we can do?
>
> I think pinning the public key could work, if the Savannah
> administrators are aware of it. But we'd need a reliable fallback
> mechanism in case the private key needs to be updated.

Yeah, sounds fragile.

> I think having a separate 'le-certs' package that can verify the Lets
> Encrypt chain sounds like the easiest option. Presumably new
> intermediates etc will be known well in advance.

That sounds more reasonable to me.  Do you know what it would take to
get the whole LE chain in such a package?  Would you like to give it a
try?

Thanks,
Ludo’.

Re: `guix pull` over HTTPS

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

On Sat, Feb 11, 2017 at 03:28:52PM +0100, Ludovic Courtès wrote:
> Marius Bakke <mbakke@fastmail.com> skribis:
> > I think pinning the public key could work, if the Savannah
> > administrators are aware of it. But we'd need a reliable fallback
> > mechanism in case the private key needs to be updated.
> 
> Yeah, sounds fragile.

My attitude about improving the security of `guix pull` can be
summarized as "The perfect is enemy of the good".

Unless we control the server that provides the default `guix pull`
source, I don't think we should try pinning a key.

I don't want to take the risk that `guix pull` breaks permamently
because something gets messed up on Savannah. If `guix pull` breaks in a
way that requires users to to do `guix pull --url=foo`, then we will
have failed, in my opinion.

I'd rather try an incremental approach, for example:

1) Fetch code over HTTPS instead of HTTP
2) Think about hosting our own infrastructure and pinning a key (but
ideally we don't have to trust the Git repo infrastructure)
3) Verify Git commit signatures
4) Think about building a set of trusted PGP keys and verifying Git 
commit signatures against this set 

... or something like that.

> > I think having a separate 'le-certs' package that can verify the Lets
> > Encrypt chain sounds like the easiest option. Presumably new
> > intermediates etc will be known well in advance.
> 
> That sounds more reasonable to me.  Do you know what it would take to
> get the whole LE chain in such a package?  Would you like to give it a
> try?

It's a good idea; let's try it.

However, I think that pulling code over HTTPS using a certificate store
like nss-certs or from the host distro is a huge improvement over what
we have now. If we can do that sooner, we should.

WDYT?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: `guix pull` over HTTPS

[Ricardo Wurmus]

Leo Famulari <leo@famulari.name> writes:

> However, I think that pulling code over HTTPS using a certificate store
> like nss-certs or from the host distro is a huge improvement over what
> we have now. If we can do that sooner, we should.

I agree.  If it’s easy to make the “le-certs” idea work I’m all for it,
but I wouldn’t mind at all if we used nss-certs here.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> However, I think that pulling code over HTTPS using a certificate store
>> like nss-certs or from the host distro is a huge improvement over what
>> we have now. If we can do that sooner, we should.
>
> I agree.  If it’s easy to make the “le-certs” idea work I’m all for it,
> but I wouldn’t mind at all if we used nss-certs here.

Agreed, let’s improve things incrementally.

Thanks,
Ludo'.

Re: `guix pull` over HTTPS

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Sat, Feb 11, 2017 at 03:28:52PM +0100, Ludovic Courtès wrote:
> Marius Bakke <mbakke@fastmail.com> skribis:
> > I think having a separate 'le-certs' package that can verify the Lets
> > Encrypt chain sounds like the easiest option. Presumably new
> > intermediates etc will be known well in advance.
> 
> That sounds more reasonable to me.  Do you know what it would take to
> get the whole LE chain in such a package?  Would you like to give it a
> try?

I tried it. The next intermediate (also called the "backup") is already
known.

I've made it available here:

https://github.com/lfam/le-certs

You can try it out:

$ echo | openssl s_client -CAfile /tmp/le-certs/le-certs.pem -CApath /tmp/le-certs -connect git.savannah.gnu.org:443

Your feedback is requested!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 4187 bytes --]

Leo Famulari <leo@famulari.name> writes:

> On Sat, Feb 11, 2017 at 03:28:52PM +0100, Ludovic Courtès wrote:
>> Marius Bakke <mbakke@fastmail.com> skribis:
>> > I think having a separate 'le-certs' package that can verify the Lets
>> > Encrypt chain sounds like the easiest option. Presumably new
>> > intermediates etc will be known well in advance.
>> 
>> That sounds more reasonable to me.  Do you know what it would take to
>> get the whole LE chain in such a package?  Would you like to give it a
>> try?
>
> I tried it. The next intermediate (also called the "backup") is already
> known.
>
> I've made it available here:
>
> https://github.com/lfam/le-certs
>
> You can try it out:
>
> $ echo | openssl s_client -CAfile /tmp/le-certs/le-certs.pem -CApath /tmp/le-certs -connect git.savannah.gnu.org:443
>
> Your feedback is requested!

Wow, this is cool!

$ SSL_CERT_FILE="" SSL_CERT_DIR=""  guix pull --url=https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz                                                        
Starting download of /tmp/guix-file.7U65Ts
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
ERROR: X.509 certificate of 'git.savannah.gnu.org' could not be verified:
  signer-not-found
  invalid

SSL_CERT_FILE="" SSL_CERT_DIR="/tmp/le-certs/"  guix pull --url=https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz
Starting download of /tmp/guix-file.wOblWP
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz                                   1.0MiB/s 00:11 | 11.1MiB transferred
unpacking '/gnu/store/p0gbr83a4g9qlk59vvxkw8gvrv1z8cnw-guix-latest.tar.gz'...

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

These certs are valid until at least 2020, so using a Guix release
snapshot of this package should work for a long time.

Some other tests:

$ 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.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: `guix pull` over HTTPS

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 3990 bytes --]

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 :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

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!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]


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

I gave this a go using "nss-certs", but can't figure out how to set
SSL_CERT_DIR (or GUIX_TLS_CERTIFICATE_DIRECTORY) in `guix pull`. The
naive approach of setting the variable before calling
"download-to-store" does not work because %x509-certificate-directory
has already been evaluated.

I wonder what's the best approach here. Parameterizing this and
propagating it all the way down to (tls-wrap) similar to
#:verify-certificate? could work, but seems awkward. Any suggestions?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1.1: Type: text/plain, Size: 1362 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

>>> 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.
>
> I gave this a go using "nss-certs", but can't figure out how to set
> SSL_CERT_DIR (or GUIX_TLS_CERTIFICATE_DIRECTORY) in `guix pull`. The
> naive approach of setting the variable before calling
> "download-to-store" does not work because %x509-certificate-directory
> has already been evaluated.
>
> I wonder what's the best approach here. Parameterizing this and
> propagating it all the way down to (tls-wrap) similar to
> #:verify-certificate? could work, but seems awkward. Any suggestions?

I made it work with the attached hack. It breaks all conventions by
allowing #:verify-certificate? to be a search path for certificates.

If it wasn't for the implied boolean nature of "#:verify-certificate?" I
would be happy with this solution. But I think setting the
GUIX_TLS_CERTIFICATE_DIRECTORY environment variable before pulling in
(guix download) would be better.


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-pull-Default-to-HTTPS.patch --]
[-- Type: text/x-patch, Size: 3101 bytes --]

From 800051909362b5817bbb386029edf14ffd8269a8 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Tue, 28 Feb 2017 22:34:29 +0100
Subject: [PATCH] pull: Default to HTTPS.

* guix/build/download.scm (tls-wrap): Allow #:verify-certificate? to be a
  search string for certificates.
* guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
(guix-pull): Verify against the store path of NSS-CERTS.
---
 guix/build/download.scm | 7 +++++--
 guix/scripts/pull.scm   | 8 ++++++--
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/guix/build/download.scm b/guix/build/download.scm
index 203338b52..88da1776f 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -342,13 +342,16 @@ way."
 
 (define* (tls-wrap port server #:key (verify-certificate? #t))
   "Return PORT wrapped in a TLS connection to SERVER.  SERVER must be a DNS
-host name without trailing dot."
+host name without trailing dot.  If VERIFY-CERTIFICATE? is a string, it is
+assumed to be the search path for TLS certificates passed to gnutls."
   (define (log level str)
     (format (current-error-port)
             "gnutls: [~a|~a] ~a" (getpid) level str))
 
   (let ((session  (make-session connection-end/client))
-        (ca-certs (%x509-certificate-directory)))
+        (ca-certs (if (string? verify-certificate?)
+                      verify-certificate?
+                      (%x509-certificate-directory))))
 
     ;; Some servers such as 'cloud.github.com' require the client to support
     ;; the 'SERVER NAME' extension.  However, 'set-session-server-name!' is
diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index a4824e4fd..402332192 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -30,6 +30,7 @@
   #:use-module ((guix build utils)
                 #:select (with-directory-excursion delete-file-recursively))
   #:use-module (gnu packages base)
+  #:use-module ((gnu packages certs) #:select (nss-certs))
   #:use-module (gnu packages guile)
   #:use-module ((gnu packages bootstrap)
                 #:select (%bootstrap-guile))
@@ -45,7 +46,7 @@
 
 (define %snapshot-url
   ;; "http://hydra.gnu.org/job/guix/master/tarball/latest/download"
-  "http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
+  "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
   )
 
 (define-syntax-rule (with-environment-variable variable value body ...)
@@ -224,8 +225,11 @@ contained therein."
   (with-error-handling
     (let* ((opts  (parse-options))
            (store (open-connection))
+           (certs (string-append (package-output store nss-certs)
+                                 "/etc/ssl/certs"))
            (url   (assoc-ref opts 'tarball-url)))
-      (let ((tarball (download-to-store store url "guix-latest.tar.gz")))
+      (let ((tarball (download-to-store store url "guix-latest.tar.gz"
+                                        #:verify-certificate? certs)))
         (unless tarball
           (leave (_ "failed to download up-to-date source, exiting\n")))
         (parameterize ((%guile-for-build
-- 
2.12.0

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> @@ -224,8 +225,11 @@ contained therein."
>    (with-error-handling
>      (let* ((opts  (parse-options))
>             (store (open-connection))
> +           (certs (string-append (package-output store nss-certs)
> +                                 "/etc/ssl/certs"))

Note: This only works if you have nss-certs in the store already. Not
sure how to convert this into a gexp.

>             (url   (assoc-ref opts 'tarball-url)))
> -      (let ((tarball (download-to-store store url "guix-latest.tar.gz")))
> +      (let ((tarball (download-to-store store url "guix-latest.tar.gz"
> +                                        #:verify-certificate? certs)))
>          (unless tarball
>            (leave (_ "failed to download up-to-date source, exiting\n")))
>          (parameterize ((%guile-for-build
> -- 
> 2.12.0

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1.1: Type: text/plain, Size: 755 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> @@ -224,8 +225,11 @@ contained therein."
>>    (with-error-handling
>>      (let* ((opts  (parse-options))
>>             (store (open-connection))
>> +           (certs (string-append (package-output store nss-certs)
>> +                                 "/etc/ssl/certs"))
>
> Note: This only works if you have nss-certs in the store already. Not
> sure how to convert this into a gexp.

Wait, this is false. For some reason I assumed package-output just
computed the store path, but it is in fact added to the store.

The attached patch adds a #:certificate-directory parameter and passes
it from (guix-pull) all the way down to (tls-wrap). Feedback wanted!


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-pull-Default-to-HTTPS.patch --]
[-- Type: text/x-patch, Size: 9587 bytes --]

From a27448b259b1d2061faabe3c17433e1c660e60c9 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Tue, 28 Feb 2017 22:34:29 +0100
Subject: [PATCH] pull: Default to HTTPS.

* guix/build/download.scm (tls-wrap): Add CERTIFICATE-DIRECTORY parameter.
(open-connection-for-uri): Adjust parameters to match.
(http-fetch): Likewise.
(url-fetch): Likewise.
* guix/download.scm (download-to-store): Likewise.
* guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
(guix-pull): Verify against the store path of NSS-CERTS.
---
 guix/build/download.scm | 40 ++++++++++++++++++++++++++++------------
 guix/download.scm       | 10 +++++++---
 guix/scripts/pull.scm   |  8 ++++++--
 3 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/guix/build/download.scm b/guix/build/download.scm
index 203338b52..2a555506a 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -340,15 +340,20 @@ way."
 (set-exception-printer! 'tls-certificate-error
                         print-tls-certificate-error)
 
-(define* (tls-wrap port server #:key (verify-certificate? #t))
+(define* (tls-wrap port server #:key (verify-certificate? #t)
+                   (certificate-directory #f))
   "Return PORT wrapped in a TLS connection to SERVER.  SERVER must be a DNS
-host name without trailing dot."
+host name without trailing dot.  If CERTIFICATE-DIRECTORY is set, x509
+certificates will be verified against those found in the specified path
+instead of the default."
   (define (log level str)
     (format (current-error-port)
             "gnutls: [~a|~a] ~a" (getpid) level str))
 
   (let ((session  (make-session connection-end/client))
-        (ca-certs (%x509-certificate-directory)))
+        (ca-certs (if (string? certificate-directory)
+                      certificate-directory
+                      (%x509-certificate-directory))))
 
     ;; Some servers such as 'cloud.github.com' require the client to support
     ;; the 'SERVER NAME' extension.  However, 'set-session-server-name!' is
@@ -459,10 +464,12 @@ ETIMEDOUT error is raised."
 (define* (open-connection-for-uri uri
                                   #:key
                                   timeout
-                                  (verify-certificate? #t))
+                                  (verify-certificate? #t)
+                                  (certificate-directory #f))
   "Like 'open-socket-for-uri', but also handle HTTPS connections.  The
 resulting port must be closed with 'close-connection'.  When
-VERIFY-CERTIFICATE? is true, verify HTTPS server certificates."
+VERIFY-CERTIFICATE? is true, verify HTTPS server certificates;
+optionally against those found in CERTIFICATE-DIRECTORY."
   (define https?
     (eq? 'https (uri-scheme uri)))
 
@@ -490,7 +497,8 @@ VERIFY-CERTIFICATE? is true, verify HTTPS server certificates."
 
        (if https?
            (tls-wrap s (uri-host uri)
-                     #:verify-certificate? verify-certificate?)
+                     #:verify-certificate? verify-certificate?
+                     #:certificate-directory certificate-directory)
            s)))))
 
 (define (close-connection port)
@@ -675,11 +683,13 @@ Return the resulting target URI."
                     #:query    (uri-query    ref)
                     #:fragment (uri-fragment ref)))))
 
-(define* (http-fetch uri file #:key timeout (verify-certificate? #t))
+(define* (http-fetch uri file #:key timeout (verify-certificate? #t)
+                     (certificate-directory #f))
   "Fetch data from URI and write it to FILE; when TIMEOUT is true, bail out if
 the connection could not be established in less than TIMEOUT seconds.  Return
 FILE on success.  When VERIFY-CERTIFICATE? is true, verify HTTPS
-certificates; otherwise simply ignore them."
+certificates, optionally against those found in CERTIFICATE-DIRECTORY;
+otherwise simply ignore them."
 
   (define post-2.0.7?
     (or (> (string->number (major-version)) 2)
@@ -709,7 +719,9 @@ certificates; otherwise simply ignore them."
                  (open-connection-for-uri uri
                                           #:timeout timeout
                                           #:verify-certificate?
-                                          verify-certificate?))
+                                          verify-certificate?
+                                          #:certificate-directory
+                                          certificate-directory))
                 ((resp bv-or-port)
                  ;; XXX: `http-get*' was introduced in 2.0.7, and replaced by
                  ;; #:streaming? in 2.0.8.  We know we're using it within the
@@ -752,7 +764,8 @@ certificates; otherwise simply ignore them."
          (close connection)
          (http-fetch uri file
                      #:timeout timeout
-                     #:verify-certificate? verify-certificate?)))
+                     #:verify-certificate? verify-certificate?
+                     #:certificate-directory certificate-directory)))
       (else
        (error "download failed" (uri->string uri)
               code (response-reason-phrase resp))))))
@@ -794,7 +807,7 @@ Return a list of URIs."
                     #:key
                     (timeout 10) (verify-certificate? #t)
                     (mirrors '()) (content-addressed-mirrors '())
-                    (hashes '()))
+                    (certificate-directory #f) (hashes '()))
   "Fetch FILE from URL; URL may be either a single string, or a list of
 string denoting alternate URLs for FILE.  Return #f on failure, and FILE
 on success.
@@ -809,7 +822,8 @@ algorithm and a hash, return a URL where the specified data can be retrieved
 or #f.
 
 When VERIFY-CERTIFICATE? is true, validate HTTPS server certificates;
-otherwise simply ignore them."
+optionally against those found in CERTIFICATE-DIRECTORY; otherwise
+simply ignore them."
   (define uri
     (append-map (cut maybe-expand-mirrors <> mirrors)
                 (match url
@@ -824,6 +838,8 @@ otherwise simply ignore them."
        (false-if-exception* (http-fetch uri file
                                         #:verify-certificate?
                                         verify-certificate?
+                                        #:certificate-directory
+                                        certificate-directory
                                         #:timeout timeout)))
       ((ftp)
        (false-if-exception* (ftp-fetch uri file
diff --git a/guix/download.scm b/guix/download.scm
index 86f859881..e4d9fbaab 100644
--- a/guix/download.scm
+++ b/guix/download.scm
@@ -548,11 +548,13 @@ own.  This helper makes it easier to deal with \"zip bombs\"."
 
 (define* (download-to-store store url #:optional (name (basename url))
                             #:key (log (current-error-port)) recursive?
-                            (verify-certificate? #t))
+                            (verify-certificate? #t)
+                            (certificate-directory #f))
   "Download from URL to STORE, either under NAME or URL's basename if
 omitted.  Write progress reports to LOG.  RECURSIVE? has the same effect as
 the same-named parameter of 'add-to-store'.  VERIFY-CERTIFICATE? determines
-whether or not to validate HTTPS server certificates."
+whether or not to validate HTTPS server certificates.  CERTIFICATE-DIRECTORY
+overrides the default search path for TLS certificates if set to a string."
   (define uri
     (string->uri url))
 
@@ -566,7 +568,9 @@ whether or not to validate HTTPS server certificates."
                   (build:url-fetch url temp
                                    #:mirrors %mirrors
                                    #:verify-certificate?
-                                   verify-certificate?))))
+                                   verify-certificate?
+                                   #:certificate-directory
+                                   certificate-directory))))
            (close port)
            (and result
                 (add-to-store store name recursive? "sha256" temp)))))))
diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index a4824e4fd..6d8ac23b5 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -30,6 +30,7 @@
   #:use-module ((guix build utils)
                 #:select (with-directory-excursion delete-file-recursively))
   #:use-module (gnu packages base)
+  #:use-module ((gnu packages certs) #:select (nss-certs))
   #:use-module (gnu packages guile)
   #:use-module ((gnu packages bootstrap)
                 #:select (%bootstrap-guile))
@@ -45,7 +46,7 @@
 
 (define %snapshot-url
   ;; "http://hydra.gnu.org/job/guix/master/tarball/latest/download"
-  "http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
+  "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
   )
 
 (define-syntax-rule (with-environment-variable variable value body ...)
@@ -224,8 +225,11 @@ contained therein."
   (with-error-handling
     (let* ((opts  (parse-options))
            (store (open-connection))
+           (certs (string-append (package-output store nss-certs)
+                                 "/etc/ssl/certs"))
            (url   (assoc-ref opts 'tarball-url)))
-      (let ((tarball (download-to-store store url "guix-latest.tar.gz")))
+      (let ((tarball (download-to-store store url "guix-latest.tar.gz"
+                                        #:certificate-directory certs)))
         (unless tarball
           (leave (_ "failed to download up-to-date source, exiting\n")))
         (parameterize ((%guile-for-build
-- 
2.12.0

Re: `guix pull` over HTTPS

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On Wed, Mar 01, 2017 at 03:36:11AM +0100, Marius Bakke wrote:
> Subject: [PATCH] pull: Default to HTTPS.
> 
> * guix/build/download.scm (tls-wrap): Add CERTIFICATE-DIRECTORY parameter.
> (open-connection-for-uri): Adjust parameters to match.
> (http-fetch): Likewise.
> (url-fetch): Likewise.
> * guix/download.scm (download-to-store): Likewise.
> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
> (guix-pull): Verify against the store path of NSS-CERTS.

When I don't have GnuTLS in my environment, it fails like this:

Starting download of /tmp/guix-file.pSCYyI
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
;;; Failed to autoload make-session in (gnutls):
;;; ERROR: missing interface for module (gnutls)
ERROR: In procedure module-lookup: Unbound variable: make-session
failed to download "/tmp/guix-file.pSCYyI" from "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
guix pull: error: failed to download up-to-date source, exiting

Also, I think we should only use a default trust store when pulling from
%snapshot-url.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v3] pull: Default to HTTPS.

[Marius Bakke]

* guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
(guix-pull): Add GNUTLS and NSS-CERTS to inputs when appropriate.
---
 guix/scripts/pull.scm | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index a4824e4fd..b9438a4f6 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -29,12 +29,16 @@
   #:use-module (guix monads)
   #:use-module ((guix build utils)
                 #:select (with-directory-excursion delete-file-recursively))
+  #:use-module ((guix build download)
+                #:select (%x509-certificate-directory))
   #:use-module (gnu packages base)
   #:use-module (gnu packages guile)
   #:use-module ((gnu packages bootstrap)
                 #:select (%bootstrap-guile))
+  #:use-module ((gnu packages certs) #:select (nss-certs))
   #:use-module (gnu packages compression)
   #:use-module (gnu packages gnupg)
+  #:use-module ((gnu packages tls) #:select (gnutls))
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-34)
   #:use-module (srfi srfi-35)
@@ -45,7 +49,7 @@
 
 (define %snapshot-url
   ;; "http://hydra.gnu.org/job/guix/master/tarball/latest/download"
-  "http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
+  "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
   )
 
 (define-syntax-rule (with-environment-variable variable value body ...)
@@ -221,11 +225,34 @@ contained therein."
                   (leave (_ "~A: unexpected argument~%") arg))
                 %default-options))
 
+  (define (use-gnutls? url)
+    (string-prefix? "https://" url))
+
+  (define (use-le-certs? url)
+    (string=? url %snapshot-url))
+
+  (define (fetch-tarball store url)
+    (download-to-store store url "guix-latest.tar.gz"))
+
   (with-error-handling
     (let* ((opts  (parse-options))
            (store (open-connection))
            (url   (assoc-ref opts 'tarball-url)))
-      (let ((tarball (download-to-store store url "guix-latest.tar.gz")))
+      (let ((tarball (if (use-gnutls? url)
+                         (begin
+                           ;; Add GnuTLS to inputs and load path.
+                           (set! %load-path
+                             (cons (string-append (package-output store gnutls)
+                                                  "/share/guile/site/"
+                                                  (effective-version))
+                                   %load-path))
+                           (if (use-le-certs? url)
+                               (parameterize ((%x509-certificate-directory
+                                               (string-append (package-output store nss-certs)
+                                                              "/etc/ssl/certs")))
+                                 (fetch-tarball store url))
+                               (fetch-tarball store url)))
+                         (fetch-tarball store url))))
         (unless tarball
           (leave (_ "failed to download up-to-date source, exiting\n")))
         (parameterize ((%guile-for-build
-- 
2.12.0

Re: [PATCH v3] pull: Default to HTTPS.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

On Wed, Mar 01, 2017 at 10:20:00PM +0100, Marius Bakke wrote:
> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
> (guix-pull): Add GNUTLS and NSS-CERTS to inputs when appropriate.

Nice! It works without GnuTLS in $PATH and an unset $SSL_CERT_DIR :)

By the way, the only thing I'm waiting for before submitting an le-certs
package is one more person to check that they can reproduce the
certificates that would be provided by the le-certs package, as
requested here:

http://lists.gnu.org/archive/html/guix-devel/2017-02/msg01146.html

>  (define %snapshot-url
>    ;; "http://hydra.gnu.org/job/guix/master/tarball/latest/download"
> -  "http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
> +  "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
>    )

> +  (define (use-le-certs? url)
> +    (string=? url %snapshot-url))

I thought about it, and we should probably relax this, to match
"https://git.savannah.gnu.org/cgit/guix.git", so that everything would
work in cases like this...

$ guix pull --url=https://git.savannah.gnu.org/cgit/guix.git/snapshot/v0.12.0.tar.gz

... and for future cases when `guix pull` may use Git.

> +  (define (fetch-tarball store url)
> +    (download-to-store store url "guix-latest.tar.gz"))
> +
>    (with-error-handling
>      (let* ((opts  (parse-options))
>             (store (open-connection))
>             (url   (assoc-ref opts 'tarball-url)))
> -      (let ((tarball (download-to-store store url "guix-latest.tar.gz")))
> +      (let ((tarball (if (use-gnutls? url)
> +                         (begin
> +                           ;; Add GnuTLS to inputs and load path.
> +                           (set! %load-path
> +                             (cons (string-append (package-output store gnutls)
> +                                                  "/share/guile/site/"
> +                                                  (effective-version))
> +                                   %load-path))
> +                           (if (use-le-certs? url)
> +                               (parameterize ((%x509-certificate-directory
> +                                               (string-append (package-output store nss-certs)
> +                                                              "/etc/ssl/certs")))
> +                                 (fetch-tarball store url))
> +                               (fetch-tarball store url)))
> +                         (fetch-tarball store url))))

I hope some more seasoned Schemers will offer their review :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

Leo Famulari <leo@famulari.name> writes:

> On Wed, Mar 01, 2017 at 03:36:11AM +0100, Marius Bakke wrote:
>> Subject: [PATCH] pull: Default to HTTPS.
>> 
>> * guix/build/download.scm (tls-wrap): Add CERTIFICATE-DIRECTORY parameter.
>> (open-connection-for-uri): Adjust parameters to match.
>> (http-fetch): Likewise.
>> (url-fetch): Likewise.
>> * guix/download.scm (download-to-store): Likewise.
>> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
>> (guix-pull): Verify against the store path of NSS-CERTS.
>
> When I don't have GnuTLS in my environment, it fails like this:
>
> Starting download of /tmp/guix-file.pSCYyI
> From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
> ;;; Failed to autoload make-session in (gnutls):
> ;;; ERROR: missing interface for module (gnutls)
> ERROR: In procedure module-lookup: Unbound variable: make-session
> failed to download "/tmp/guix-file.pSCYyI" from "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
> guix pull: error: failed to download up-to-date source, exiting
>
> Also, I think we should only use a default trust store when pulling from
> %snapshot-url.

Please try version 3 of the patch, where I tried to address these
issues. It is also far simpler than the previous approaches.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Mar 01, 2017 at 03:36:11AM +0100, Marius Bakke wrote:
>> Subject: [PATCH] pull: Default to HTTPS.
>> 
>> * guix/build/download.scm (tls-wrap): Add CERTIFICATE-DIRECTORY parameter.
>> (open-connection-for-uri): Adjust parameters to match.
>> (http-fetch): Likewise.
>> (url-fetch): Likewise.
>> * guix/download.scm (download-to-store): Likewise.
>> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
>> (guix-pull): Verify against the store path of NSS-CERTS.
>
> When I don't have GnuTLS in my environment, it fails like this:
>
> Starting download of /tmp/guix-file.pSCYyI
> From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
> ;;; Failed to autoload make-session in (gnutls):
> ;;; ERROR: missing interface for module (gnutls)
> ERROR: In procedure module-lookup: Unbound variable: make-session
> failed to download "/tmp/guix-file.pSCYyI" from "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
> guix pull: error: failed to download up-to-date source, exiting

What about making GnuTLS a hard requirement for Guix?

Ludo’.

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Hi!

Marius Bakke <mbakke@fastmail.com> skribis:

> From 800051909362b5817bbb386029edf14ffd8269a8 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Tue, 28 Feb 2017 22:34:29 +0100
> Subject: [PATCH] pull: Default to HTTPS.
>
> * guix/build/download.scm (tls-wrap): Allow #:verify-certificate? to be a
>   search string for certificates.
> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
> (guix-pull): Verify against the store path of NSS-CERTS.
> ---
>  guix/build/download.scm | 7 +++++--
>  guix/scripts/pull.scm   | 8 ++++++--
>  2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/guix/build/download.scm b/guix/build/download.scm
> index 203338b52..88da1776f 100644
> --- a/guix/build/download.scm
> +++ b/guix/build/download.scm
> @@ -342,13 +342,16 @@ way."
>  
>  (define* (tls-wrap port server #:key (verify-certificate? #t))
>    "Return PORT wrapped in a TLS connection to SERVER.  SERVER must be a DNS
> -host name without trailing dot."
> +host name without trailing dot.  If VERIFY-CERTIFICATE? is a string, it is
> +assumed to be the search path for TLS certificates passed to gnutls."
>    (define (log level str)
>      (format (current-error-port)
>              "gnutls: [~a|~a] ~a" (getpid) level str))
>  
>    (let ((session  (make-session connection-end/client))
> -        (ca-certs (%x509-certificate-directory)))
> +        (ca-certs (if (string? verify-certificate?)
> +                      verify-certificate?
> +                      (%x509-certificate-directory))))

Nitpick: I would prefer to use a different argument for the certificate
directory.  Something like this:

  (define* (tls-wrap port server #:key (verify-certificate? #t)
                                 (certificate-directory
                                  (%x509-certificate-directory)))
    …)                                 

Also the ‘guix pull’ part should be a separate patch.

Great work, thank you!

Ludo’.

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> From 800051909362b5817bbb386029edf14ffd8269a8 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke <mbakke@fastmail.com>
>> Date: Tue, 28 Feb 2017 22:34:29 +0100
>> Subject: [PATCH] pull: Default to HTTPS.
>>
>> * guix/build/download.scm (tls-wrap): Allow #:verify-certificate? to be a
>>   search string for certificates.
>> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
>> (guix-pull): Verify against the store path of NSS-CERTS.
>> ---
>>  guix/build/download.scm | 7 +++++--
>>  guix/scripts/pull.scm   | 8 ++++++--
>>  2 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/guix/build/download.scm b/guix/build/download.scm
>> index 203338b52..88da1776f 100644
>> --- a/guix/build/download.scm
>> +++ b/guix/build/download.scm
>> @@ -342,13 +342,16 @@ way."
>>  
>>  (define* (tls-wrap port server #:key (verify-certificate? #t))
>>    "Return PORT wrapped in a TLS connection to SERVER.  SERVER must be a DNS
>> -host name without trailing dot."
>> +host name without trailing dot.  If VERIFY-CERTIFICATE? is a string, it is
>> +assumed to be the search path for TLS certificates passed to gnutls."
>>    (define (log level str)
>>      (format (current-error-port)
>>              "gnutls: [~a|~a] ~a" (getpid) level str))
>>  
>>    (let ((session  (make-session connection-end/client))
>> -        (ca-certs (%x509-certificate-directory)))
>> +        (ca-certs (if (string? verify-certificate?)
>> +                      verify-certificate?
>> +                      (%x509-certificate-directory))))
>
> Nitpick: I would prefer to use a different argument for the certificate
> directory.  Something like this:
>
>   (define* (tls-wrap port server #:key (verify-certificate? #t)
>                                  (certificate-directory
>                                   (%x509-certificate-directory)))
>     …)                                 
>
> Also the ‘guix pull’ part should be a separate patch.
>
> Great work, thank you!

Hello!

Please see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25975

... for the latest version of this patch.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: `guix pull` over HTTPS

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]

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.

The ISRG trust chain is supported by NSS since 3.26[0] and Firefox 50.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1204656

As long as the ISRG chain works with all software in Guix, I don't see a
reason to include the IdenTrust root and intermediates. I think we
should not include the retired intermediate certificates however.

This tiny chain works for all cases I've tried:

cat isrgrootx1.pem letsencryptauthorityx3.pem letsencryptauthorityx4.pem > le-certs.pem

> 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 downloaded each certificate independently and ran the provided 'sed'
command and ended up with the same SHA256 hashes, which are:

139a5e4a4e0fa505378c72c5f700934ce8333f4e6b1b508886c4b0eb14f4be99  dstrootx3.pem
3e6cf961c196c63a39bd99e5e34ff42c83669e3d7bcc2e4a0f9c7c7df40d0d7e  isrgrootx1.pem
3acb088b1372351a29c23ba51d28442a22e810224f8d009d8e026c470f463d74  le-certs.pem
f8a8316dcc1f813774e7d7e2f85d7069d8b387c98a81b6073ef9f415be62410e  letsencryptauthorityx1.pem
3f67c48667781f7a7221320ee5b76c353aa4e0f4b2ed24a8a41113e6638f9724  letsencryptauthorityx2.pem
735a28bd5d93161769dd3a5d1d6337f24d1f2662cfe355930c1cffc38cac6a7d  letsencryptauthorityx3.pem
04f703429322d699af9e4d47e558cb696378fa20073700c9309263c448626d00  letsencryptauthorityx4.pem
6c0a324bb803e9d66b8986ea2085bb9d6bdfe33f5c04a03a3f7024f4aa8e7a2d  lets-encrypt-x1-cross-signed.pem
b5791649cc21518a9757d7e1809bc47c5e60edc45c9dddaaf6c060cbe03bcb1d  lets-encrypt-x2-cross-signed.pem
e446c5e9dbef9d09ac9f7027c034602492437a05ff6c40011d7235fca639c79a  lets-encrypt-x3-cross-signed.pem
f524491d9c2966c01ecec75c7803c7169ff46bc5cfd44c396d418cd7053d8015  lets-encrypt-x4-cross-signed.pem

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: `guix pull` over HTTPS

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

On Wed, Mar 01, 2017 at 12:05:57AM +0100, Marius Bakke wrote:
> The ISRG trust chain is supported by NSS since 3.26[0] and Firefox 50.
> 
> [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1204656
> 
> As long as the ISRG chain works with all software in Guix, I don't see a
> reason to include the IdenTrust root and intermediates. I think we
> should not include the retired intermediate certificates however.
> 
> This tiny chain works for all cases I've tried:
> 
> cat isrgrootx1.pem letsencryptauthorityx3.pem letsencryptauthorityx4.pem > le-certs.pem

I've updated the le-certs Git repo to include this bundle (although I
put the root certificate at the end of the list), and a separate bundle
for the IdenTrust-signed chain.

Let's use the ISRG chain.

> > 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 downloaded each certificate independently and ran the provided 'sed'
> command and ended up with the same SHA256 hashes, which are:
> 
> 139a5e4a4e0fa505378c72c5f700934ce8333f4e6b1b508886c4b0eb14f4be99  dstrootx3.pem
> 3e6cf961c196c63a39bd99e5e34ff42c83669e3d7bcc2e4a0f9c7c7df40d0d7e  isrgrootx1.pem
> 3acb088b1372351a29c23ba51d28442a22e810224f8d009d8e026c470f463d74  le-certs.pem
> f8a8316dcc1f813774e7d7e2f85d7069d8b387c98a81b6073ef9f415be62410e  letsencryptauthorityx1.pem
> 3f67c48667781f7a7221320ee5b76c353aa4e0f4b2ed24a8a41113e6638f9724  letsencryptauthorityx2.pem
> 735a28bd5d93161769dd3a5d1d6337f24d1f2662cfe355930c1cffc38cac6a7d  letsencryptauthorityx3.pem
> 04f703429322d699af9e4d47e558cb696378fa20073700c9309263c448626d00  letsencryptauthorityx4.pem
> 6c0a324bb803e9d66b8986ea2085bb9d6bdfe33f5c04a03a3f7024f4aa8e7a2d  lets-encrypt-x1-cross-signed.pem
> b5791649cc21518a9757d7e1809bc47c5e60edc45c9dddaaf6c060cbe03bcb1d  lets-encrypt-x2-cross-signed.pem
> e446c5e9dbef9d09ac9f7027c034602492437a05ff6c40011d7235fca639c79a  lets-encrypt-x3-cross-signed.pem
> f524491d9c2966c01ecec75c7803c7169ff46bc5cfd44c396d418cd7053d8015  lets-encrypt-x4-cross-signed.pem

Thanks, that matches what I have. One more person, please :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH] pull: Use HTTPS by default.

[Marius Bakke]

* guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
(%options): Add "--insecure" option.
(show-help): Mention it.
(guix-pull): Pass #:verify-certificate to DOWNLOAD-TO-STORE.
---
 guix/scripts/pull.scm | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index a4824e4fd..b1724f13c 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -45,7 +45,7 @@
 
 (define %snapshot-url
   ;; "http://hydra.gnu.org/job/guix/master/tarball/latest/download"
-  "http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
+  "https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"
   )
 
 (define-syntax-rule (with-environment-variable variable value body ...)
@@ -78,6 +78,8 @@ Download and deploy the latest version of Guix.\n"))
   (display (_ "
       --url=URL          download the Guix tarball from URL"))
   (display (_ "
+      --insecure         do not perform validation of TLS certificates"))
+  (display (_ "
       --bootstrap        use the bootstrap Guile to build the new Guix"))
   (newline)
   (display (_ "
@@ -96,6 +98,9 @@ Download and deploy the latest version of Guix.\n"))
                 (lambda (opt name arg result)
                   (alist-cons 'tarball-url arg
                               (alist-delete 'tarball-url result))))
+        (option '("insecure") #f #f
+                (lambda (opt name arg result)
+                  (alist-cons 'insecure? #t result)))
         (option '("bootstrap") #f #f
                 (lambda (opt name arg result)
                   (alist-cons 'bootstrap? #t result)))
@@ -225,7 +230,9 @@ contained therein."
     (let* ((opts  (parse-options))
            (store (open-connection))
            (url   (assoc-ref opts 'tarball-url)))
-      (let ((tarball (download-to-store store url "guix-latest.tar.gz")))
+      (let ((tarball (download-to-store store url "guix-latest.tar.gz"
+                                        #:verify-certificate?
+                                        (not (assoc-ref opts 'insecure?)))))
         (unless tarball
           (leave (_ "failed to download up-to-date source, exiting\n")))
         (parameterize ((%guile-for-build
-- 
2.12.0

Re: [PATCH] pull: Use HTTPS by default.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

On Tue, Feb 28, 2017 at 05:39:02PM +0100, Marius Bakke wrote:
> * guix/scripts/pull.scm (%snapshot-url): Use HTTPS.
> (%options): Add "--insecure" option.

I hope that we can make it reliable enough that we don't need a special
option. In that case, users would instead pass the option
'--url=http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz'

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: `guix pull` over HTTPS

[Christopher Allan Webber]

Leo Famulari writes:

> On Thu, Feb 09, 2017 at 04:55:12PM +0100, Leo Famulari wrote:
>> Does anyone have any specific concerns or advice about changing the
>> value of %snapshot-url in (guix scripts pull) to use the HTTPS URL?
>> Should the change be that simple, or should we do more?
>
> While testing, I realized that an X.509 certificate store is not a
> standard feature of GuixSD, so using Savannah's HTTPS URL will not work
> in all cases.

Maybe it should become standard?

> SSL_CERT_FILE and SSL_CERT_DIR appear to be set unconditionally in (gnu
> system operating-system-environment-variables), so it's not enough to
> test that they are set in order to decide which protocol to download the
> Guix source code with.
>
> Any advice on how to proceed?

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Hi Leo!

Leo Famulari <leo@famulari.name> skribis:

> HTTPS is not a security panacea but, in my opinion, we should use it if
> it's available, at least until `guix pull` can verify commit signatures.

Agreed.  At least it prevents eavesdropping and allows us to
authenticate the server (assuming the CA is trustworthy).

But as you write, the eventual goal is to authenticate the code rather
the server, which will provide much better assurance.

> However, it's a little harder to get right than HTTP. For example, `guix
> pull` could fail if there is a problem with the user's certificate
> store, or if their clock is wrong.
>
> Does anyone have any specific concerns or advice about changing the
> value of %snapshot-url in (guix scripts pull) to use the HTTPS URL?
> Should the change be that simple, or should we do more?

I think it should be this simple.

Of course there will be issues with people having the wrong SSL_CERT_DIR
& co. settings.  Also that means Guile-GnuTLS becomes a hard dependency,
which I think is fine.

Thanks,
Ludo’.

Re: `guix pull` over HTTPS

[Bob Proulx]

[-- Attachment #1: Type: text/plain, Size: 3036 bytes --]



Leo Famulari wrote:
> GNU Guix is discussing the possibilities created by Savannah's
> offering of Git-over-HTTPS:
...
> If anyone from Savannah has anything to add to the discussion, feel
> free to jump in :)

Thanks for the invite!  I'll jump in. :-)

I am not subscribed.  Please CC me on anything you want me to see.
Although I will check back periodically it won't be timely.

I see many things over multiple messages.  I will try to coalesce
several things here in one place.

> The Savannah admins have been working tirelessly to improve the Savannah
> infrastructure, and they will soon announce the public availability of
> Git served over HTTPS. [1]

I think things are working pretty solidly.  After having previously
needed several flip-flops back and forth I think things are going to
stick in the current configuration now.  Haven't had any new
showstopper problem reports recently and I think by now there would
have been reports if something was significantly problematic.

I need to write up a more official announcement but I think it is safe
to rely upon using the current git over https configuration.

Ludovic Courtès wrote:
> Alternately we could have a package that provides only the Let’s
> Encrypt certificate chain, if that’s what Savannah uses.

Yes.  Previously the FSF furnished purchased static certificates
yearly but with this migration we are now using Let's Encrypt on all
of the Savannah servers.

As you know Let's Encrypt have a maximum expiration of three months.
The typical renewal schedule is to check daily and renew after two
months giving a month of schedule exposure to ensure renewal before
expiration.  In practice this means the certificates are renewed and
updated every two months.

There have been problems elsewhere with people pinning certificates on
their client and then finding that every two months they get a
certificate change notice.  With Let's Encrypt that is every two
months but even with the previous commercial authority that change
occurred every year.

Marius Bakke wrote:
> I think pinning the public key could work, if the Savannah
> administrators are aware of it. But we'd need a reliable fallback
> mechanism in case the private key needs to be updated.

As you note the are both advantages and disadvantages to certificate
pinning.  At the moment we are not planning on implementing pinning.
This is not a permanent statement.  Just the current state of things
at this time.  Continuous incremental improvement is happening.

Ludovic Courtès wrote:
> Agreed, let’s improve things incrementally.

That is a good summary of my own philosophy too.

> But as you write, the eventual goal is to authenticate the code rather
> the server, which will provide much better assurance.

As a long time user of a distro that does that I agree completely and
would like to encourage this.  And of course then it would work on
other transports such as physical media and other paths. :-)

Bob

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]