bug#48103: 28.0.50; tls connection failing on invoking package-list-packages (and other operations)

[Robert Pluim]

>>>>> On Wed, 05 May 2021 11:20:27 +0200, Lars Ingebrigtsen <larsi@gnus.org> 
>>>>> said:

    Lars> wilde@sha-bang.de writes:
    >>> Perhaps the version of gnutls on NetBSD doesn't support TLS 1.3?
    >> 
    >> On my NetBSD system:
    >> 
    >> % gnutls-cli -l | grep -i tls1.3
    >> TLS_AES_128_GCM_SHA256             0x13, 0x01      TLS1.3
    >> TLS_AES_256_GCM_SHA384             0x13, 0x02      TLS1.3
    >> TLS_CHACHA20_POLY1305_SHA256       0x13, 0x03      TLS1.3
    >> TLS_AES_128_CCM_SHA256             0x13, 0x04      TLS1.3
    >> TLS_AES_128_CCM_8_SHA256           0x13, 0x05      TLS1.3
    >> Protocols: VERS-TLS1.0, VERS-TLS1.1, VERS-TLS1.2, VERS-TLS1.3, 
VERS-DTLS0.9, 
    >> VERS-DTLS1.0, VERS-DTLS1.2
    >> 
    >> This output is identical to the output I get on my GNU/Linux system
    >> where the system does not exist.  So I'd assume the TLS 1.3 support does
    >> not differ...

    Lars> Doesn't sound like it, no, so I'm guessing there's something
    Lars> timing-related and a problem with retries.  Unfortunately, I'm not 
able
    Lars> to build Emacs at all under Netbsd 9.0 (which is the version I have
    Lars> here), so I'll have to install a new VM with 9.1 to do some testing.

    Lars> That might take a while, though, so if somebody else can poke at this,
    Lars> that'd be nice.  :-)

I had a quick look at what gnutls-cli does differently, and it sets a
timeout on the handshake, but that then requires you to supply a
timeout callback, which ends up calling select. gnutls-cli sets a
timeout of 40 seconds, but I guess we could set something shorter, but
then I worry about the effect of calling select from outside
wait_reading_process_output.

Robert
--