From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#34102: [staging] Guix fails to download from TLSv1.3-enabled servers Date: Fri, 25 Jan 2019 14:43:41 +0100 Message-ID: <87sgxgq2cy.fsf@gnu.org> References: <875zuoiv6s.fsf@fastmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:49879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gn1uk-0006LB-T0 for bug-guix@gnu.org; Fri, 25 Jan 2019 08:52:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gn1m9-0000kc-Iu for bug-guix@gnu.org; Fri, 25 Jan 2019 08:44:06 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:45358) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gn1m9-0000kP-Dk for bug-guix@gnu.org; Fri, 25 Jan 2019 08:44:05 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <875zuoiv6s.fsf@fastmail.com> (Marius Bakke's message of "Wed, 16 Jan 2019 14:33:15 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Marius Bakke Cc: 34102@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Marius, Marius Bakke 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 `(# 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 =E2=80=98gnutls_reauth=E2=80=99, which are currently missing. Would you li= ke to give it a try? What=E2=80=99s 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=E2=80=99s a stop-gap measure we should probably apply for now: --=-=-= Content-Type: text/x-patch Content-Disposition: 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 . ;; Explicitly disable SSLv3, which is insecure: ;; . - (set-session-priorities! session "NORMAL:%COMPAT:-VERS-SSL3.0") + ;; + ;; FIXME: Since we currently fail to handle TLS 1.3, remove it; see + ;; . + (set-session-priorities! session "NORMAL:%COMPAT:-VERS-SSL3.0:-VERS-TLS1.3") (set-session-credentials! session (if (and verify-certificate? ca-certs) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Any objections? Thanks, Ludo=E2=80=99. --=-=-=--