GNU bug report logs - #36017
27.0.50; TLS 1.3 on macOS exhibits similar issue to #34341

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: 36017 <at> debbugs.gnu.org
Cc: Joseph Mingrone <jrm <at> ftfl.ca>, Robert Pluim <rpluim <at> gmail.com>, Noam Postavsky <npostavs <at> gmail.com>, Aaron Jensen <aaronjensen <at> gmail.com>
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?

Previous Next

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