GNU bug report logs - #34102
[staging] Guix fails to download from TLSv1.3-enabled servers

Previous Next

Package: guix;

Reported by: Marius Bakke <mbakke <at> fastmail.com>

Date: Wed, 16 Jan 2019 13:34:01 UTC

Severity: serious

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 34102 <at> debbugs.gnu.org
Subject: bug#34102: [staging] Guix fails to download from TLSv1.3-enabled servers
Date: Fri, 25 Jan 2019 14:43:41 +0100
[Message part 1 (text/plain, inline)]
Hi Marius,

Marius Bakke <mbakke <at> fastmail.com> skribis:

> On the staging branch (with GnuTLS 3.6), `guix download` will negotiate
> TLSv1.3 with servers that support it, and fail shortly after the initial
> handshake:
>
> $ ./pre-inst-env guix download https://data.iana.org
> Starting download of /tmp/guix-file.vJ4v7h
> From https://data.iana.org...
> Throw to key `gnutls-error' with args `(#<gnutls-error-enum Resource temporarily unavailable, try again.> read_from_session_record_port)'.
> failed to download "/tmp/guix-file.vJ4v7h" from "https://data.iana.org"
> guix download: error: https://data.iana.org: download failed

Ouch, thanks for the heads-up!

> The GnuTLS maintainer have written a blog post about TLS 1.3 porting[0],
> and I suspect the problem is that Guix (or the GnuTLS Guile bindings)
> does not handle the "GNUTLS_E_REAUTH_REQUEST" error code; however my
> attempts at catching it (or any error code) has been unfruitful.

I think we need to update the Guile bindings to wrap
GNUTLS_E_REAUTH_REQUEST, GNUTLS_POST_HANDSHAKE_AUTH, and
‘gnutls_reauth’, which are currently missing.  Would you like to give it
a try?

What’s unclear to me from the blog post is exactly when
GNUTLS_E_REAUTH_REQUEST is delivered to the application.  Is it the next
time the application calls some (possibly unrelated) GnuTLS function?

> This is an obvious merge blocker, help wanted!  Disabling TLS1.3 in the
> priority string works as a last-resort workaround.

Yes, that’s a stop-gap measure we should probably apply for now:

[Message part 2 (text/x-patch, inline)]
diff --git a/guix/build/download.scm b/guix/build/download.scm
index c08221b3b2..23c9a4d466 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -268,7 +268,10 @@ host name without trailing dot."
     ;; "(gnutls) Priority Strings"); see <http://bugs.gnu.org/23311>.
     ;; Explicitly disable SSLv3, which is insecure:
     ;; <https://tools.ietf.org/html/rfc7568>.
-    (set-session-priorities! session "NORMAL:%COMPAT:-VERS-SSL3.0")
+    ;;
+    ;; FIXME: Since we currently fail to handle TLS 1.3, remove it; see
+    ;; <https://bugs.gnu.org/34102>.
+    (set-session-priorities! session "NORMAL:%COMPAT:-VERS-SSL3.0:-VERS-TLS1.3")
 
     (set-session-credentials! session
                               (if (and verify-certificate? ca-certs)
[Message part 3 (text/plain, inline)]
Any objections?

Thanks,
Ludo’.

This bug report was last modified 5 years and 118 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.