[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36017: 27.0.50; TLS 1.3 on macOS exhibits similar issue to #34341
From: |
Mattias Engdegård |
Subject: |
bug#36017: 27.0.50; TLS 1.3 on macOS exhibits similar issue to #34341 |
Date: |
Mon, 7 Oct 2019 17:02:25 +0200 |
There seems to be a race of some kind.
On macOS 10.14 and Emacs master, NS build, `list-packages' (with only
elpa.gnu.org configured) fails while fetching archive-contents asynchronously.
However, running
(url-retrieve
"https://elpa.gnu.org/packages/archive-contents"
(lambda (status) (message "callback: status = %S" status))
nil
'silent)
works (albeit slowly); this is (modulo the callback) what list-packages does
behind the curtains. The only difference is that list-packages then immediately
proceeds with some other work (package-menu--refresh). This can be simulated
with
(progn
(url-retrieve ...) ; like above
(busy-wait 1.0)) ; busy-wait 1 s
which fails in the same way. As reported by Joseph Mingrone, the process
sentinel, `url-http-async-sentinel', is called with a WHY argument of
"connect", which makes little sense; if the process is still trying to connect,
why is the sentinel called?
In any case, `url-http-async-sentinel' interprets the "connect" status as an
error and fails, but this is just a symptom of something earlier; changing the
sentinel to ignore "connect" doesn't help.
If run in a TTY (with -nw), everything works, further indicating that it's may
be a problem with handling of asynchronous processes in the NS build.
However, this seems insufficient by itself: is gnutls (or TLS 1.3) really so
brittle that it cannot cope with a mere delay of 1 s during the initial
handshake?
More details:
* In all runs, gnutls_handshake fails when called right after the initial
connect() in connect_network_socket; this is expected since the socket is
nonblocking and the TCP connection hasn't been set up yet.
* In failed runs, gnutls_handshake succeeds immediately in
wait_reading_process_output.
* In successful runs, gnutls_handshake initially fails (with GNUTLS_E_AGAIN) in
wait_reading_process_output. Only after several tries does it return success.
I didn't make much progress beyond this point. Could someone more familiar with
gnutls in Emacs help me debug it?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#36017: 27.0.50; TLS 1.3 on macOS exhibits similar issue to #34341,
Mattias Engdegård <=