GNU bug report logs - #32658
26.1; Cannot connect to TLS websites

Previous Next

Full log

Message #26 received at 32658 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: thomas <at> m3y3r.de
Cc: Eli Zaretskii <eliz <at> gnu.org>, 32658 <at> debbugs.gnu.org
Subject: Re: bug#32658: gnutls + non-blocking url-retrieve
Date: Thu, 16 May 2019 09:14:56 -0400

thomas <at> m3y3r.de writes:

>>>> From: thomas <at> m3y3r.de
>>>> 
>>>> 1.) I needed to revert to gnutls 3.5.19, the mingw64 build from the
>>>> gitlab ci build seems to have a working gnutls-cli tools on windows 10.
>>>> the gitlab builds for 3.6.3 and 3.6.4 seems to have another bug
>>>> (error code -53) in the gnutls-cli command.
>>>> 
>>>> so only gnutls 3.5.19 have a working gnutls-cli. i installed this version in emacs 26.1

> okay, some more infos.
>
> I was able to bootstrap the emacs compile with mingw64.
>
> while I was trying to debug this problem with fprintf, eww suddenly
> started to work!!
>
> It started to work after I did insert an fprintf after the
> gnutls_try_handshake call in process.c !!
>
> what is going on here?

It sounds like this might be Bug#34341, the problem was
emacs_gnutls_read didn't handle GNUTLS_E_AGAIN properly.  The symptoms
only seem to occur with servers supporting TLS1.3 and more recent gnutls
versions (I thought it was 3.6+, but I haven't pinned the precise
version numbers, so maybe 3.5.19 has it too, or maybe it's a bit
different on Windows).  And some people reported that increasing
gnutls-log-level made it go away, so it's certainly timing dependent.

So can you check if the problem is fixed in the latest emacs-26 or
master branch?

https://debbugs.gnu.org/34341

Previous Next

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