Re: `guix pull` over HTTPS

[Marius Bakke]

Ludovic Courtès  writes:

> Hi!
>
> Marius Bakke  skribis:
>
>> From 800051909362b5817bbb386029edf14ffd8269a8 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke 
>> 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.


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Hi!

Marius Bakke  skribis:

> From 800051909362b5817bbb386029edf14ffd8269a8 Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> 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

[Ludovic Courtès]

Leo Famulari  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

[Marius Bakke]

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


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Leo Famulari]

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.


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Marius Bakke]

Marius Bakke  writes:

> Marius Bakke  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!



signature.asc
Description: PGP signature
>From a27448b259b1d2061faabe3c17433e1c660e60c9 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
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..2a06a 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-queryref)
 #: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?
- 

Re: `guix pull` over HTTPS

[Leo Famulari]

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


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Marius Bakke]

Leo Famulari  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


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Marius Bakke]

Marius Bakke  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


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Marius Bakke]

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



signature.asc
Description: PGP signature
>From 800051909362b5817bbb386029edf14ffd8269a8 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
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]

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


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Marius Bakke]

Leo Famulari  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!


signature.asc
Description: PGP signature

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

Re: `guix pull` over HTTPS

[Marius Bakke]

Leo Famulari  writes:

> On Sat, Feb 11, 2017 at 03:28:52PM +0100, Ludovic Courtès wrote:
>> Marius Bakke  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.



signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Leo Famulari]

On Sat, Feb 11, 2017 at 03:28:52PM +0100, Ludovic Courtès wrote:
> Marius Bakke  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!


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Bob Proulx]

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


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Leo Famulari  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

[Ricardo Wurmus]

Leo Famulari  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

[Leo Famulari]

On Sat, Feb 11, 2017 at 03:28:52PM +0100, Ludovic Courtès wrote:
> Marius Bakke  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?


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
>> Marius Bakke  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

[ng0]

On 17-02-10 23:43:45, Marius Bakke wrote:
> Ludovic Courtès  writes:
> 
> > Marius Bakke  skribis:
> >
> >> Ludovic Courtès  writes:
> >>
> >>> Leo Famulari  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

[Marius Bakke]

Ludovic Courtès  writes:

> Marius Bakke  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Leo Famulari  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.


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
>> Leo Famulari  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

[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

[Marius Bakke]

Ludovic Courtès  writes:

> Leo Famulari  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


signature.asc
Description: PGP signature

Re: `guix pull` over HTTPS

[Ludovic Courtès]

Leo Famulari  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

[Ludovic Courtès]

Hi Leo!

Leo Famulari  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

[Leo Famulari]

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?


signature.asc
Description: PGP signature