Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

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>