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