Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused
Guilhem Moulin
guilhem at debian.org
Wed Apr 10 14:22:09 BST 2019
On Tue, 09 Apr 2019 at 23:39:31 +0200, Guilhem Moulin wrote:
> AFAICT this worked this time because the socket was *only* marked as
> ready for writing after the first select() call. Only during the second
> call was there some data to be read:
>
>> select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 1 (out [3], left {tv_sec=179, tv_usec=999996})
>> select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left {tv_sec=179, tv_usec=977469})
>
> I'm unable to reproduce this with v1.3, probably due to race conditions.
Forgot to add this, sorry: perhaps the reproducibility of this issue is
improved when one connects to the loopback interface rather than to a
remote TLS termination proxy? (Even though I suppose it doesn't
completely eliminate the race.)
In a clean sid chroot, after `apt install --no-install-recommends strace
liblwp-protocol-https-perl libio-socket-ssl-perl libnet-ssleay-perl`:
## Start a loopback-bound TLS (v1.3 only) server in a terminal
$ openssl req -x509 -keyout /tmp/key.pem -out /tmp/cert.pem -subj /CN=127.0.0.1 -nodes
$ openssl s_server -accept 127.0.0.1:4433 -key /tmp/key.pem -cert /tmp/cert.pem -tls1_3
## Connect to it from another terminal and send an HTTP POST request
$ patch -p2 </tmp/0001-deal-with-OpenSSL-1.1.1-switching-on-SSL_AUTO_RETRY-.patch
$ strace -etrace=select,read perl -MLWP::UserAgent -e \
'LWP::UserAgent->new(ssl_opts => {SSL_ca_file => "/tmp/cert.pem"})->
post("https://127.0.0.1:4433", {data => "foo"})'
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], left {tv_sec=179, tv_usec=999998})
read(3, "…", 5) = 5
read(3, "…", 234) = 234
read(3, "…", 5) = 5
read(3, "…", 250) = 250
read(3,
This does hang *anyway* but it should hang *after* sending the request
out to the server (ie when waiting for the HTTP reply), not *before* any
application data was sent, unlike the above. AFAICT the local server
never receives “POST / HTTP/1.1\r\n” when select(2) marks the socket as
ready both for reads and writes client-side, whether the patch is
applied or not.
Not setting the SSL_MODE_AUTO_RETRY flag back after removing O_NONBLOCK
(ie commenting out `Net::SSLeay::set_mode($ssl, $mode_auto_retry);` in
the patch) solves the problem with blocking I/O and select/poll, but
breaks programs expecting SSL_read() to block until application data
comes in. (That is, programs not conforming to SSL_read()'s documented
behavior — hence which would break on renegotiation with TLS <1.3; or
programs relying on SSL_MODE_AUTO_RETRY being set, as in OpenSSL ≥1.1.1's
default context flags.)
--
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/attachments/20190410/bd0058bd/attachment.sig>
More information about the pkg-perl-maintainers
mailing list