GNU bug report logs -
#49449
28: TLS connection never gets to "open" stage
Previous Next
Full log
View this message in rfc822 format
Mattias Engdegård <mattiase <at> acm.org> writes:
> (B) In wait_reading_process_output, after the descriptor being found writable by `select` and the condition
>
> NILP (p->gnutls_boot_parameters) && !p->gnutls_p
>
> being satisfied (process.c:5900).
>
> There seems to be a gap in the logic, however: it is perfectly
> possible for the condition in (A) to fail because the descriptor is
> still marked nonblocking at that point, and for (B) to fail because
> gnutls_p=true was set already in gnutls_try_handshake.
>
> Lars, it looks like you wrote at least part of the original logic. Can
> you see what is going on? It is somewhat complex.
Yes, it's grown somewhat organically. :-/
> For reference, I'm using the reproduction recipe below; it may or may not exhibit the problem in your particular setup. I'm using gnutls 3.6.15.
>
> (defun busy-wait (s)
> (let ((t0 (current-time)))
> (while (< (time-to-seconds (time-since t0)) s) nil)))
>
> (progn
> (url-http
> #s(url "https" nil nil "elpa.gnu.org" nil "/packages/archive-contents" nil nil t silent t t)
> (lambda (status) (message "callback: status = %S" status))
> '(nil) nil 'tls)
> (busy-wait 1.0))
I'm not able to reproduce this on Debian/bullseye, but on Macos I get
callback: status = (:error (error connection-failed "connect" :host "elpa.gnu.o\
rg" :service 443))
after a while. There's been several reports in the last week of TLS not
working on Macos. Has Apple pushed something new, or... did something
else happen lately in this area on Macos?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
This bug report was last modified 3 years and 311 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.