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

[Steffen Ullrich]

> Ah I see, thanks for the clarification.  I thought you meant it could
> yield a deadlock.  Aren't temporary failures also possible on plain
> sockets (though of course the extra SSL layer make it strictly more
> likely to happen)?  IIRC if the checksum of the incoming packet
> mismatches, which causes the read() call to block until the packet is
> retransmitted.

select only shows an fd ready  if data are available for read in the socket
buffer. Data with wrong checksum are discarded by the kernel before they are
put into the socket buffer and thus don't cause select to show it ready for
read.

select(2) explicitly says:

  A file descriptor is considered ready if it is possible to perform a
  corresponding I/O operation (e.g., read(2)  without blocking ...

> > And while using blocking I/O with polling sockets might be fine with plain
> > sockets where each byte is part of application data it is not fine with SSL
> > since the unit in SSL is not a byte but a record and some records might
> > contain application data and some not.
>
> Why is that not fine, if the SSL_read() caller is ready for that (documented)
> outcome, and doesn't assume that the call will always block until some
> application data is received?

IO::Socket::SSL is intended as abstraction which behaves as much as possible
as other IO::Socket classes. It is not intended that the developer has to be
familiar with the exact semantics of SSL_read (which also changed over
time, especially with OpenSSL 1.1.0 and again with OpenSSL 1.1.1). While it
is impossible to behave in exactly all cases sysread is usually not expect
to return a temporary error on a blocking socket.

> Then I don't get it.  AFAICT the current documentation reflects what
> happens with blocking sockets and OpenSSL <1.1.1a, namely that
> IO::Socket::SSL::sysread() returns undef when the TLS ≤1.2 session is
> renegotiated.  Are you saying that the intention was to keep retrying
> (either Perl-side, or within SSL_read() via SSL_MODE_AUTO_RETRY with
> OpenSSL ≥0.9.6) until application data is received or a fatal error is
> encountered?

Yes, the intention was to reflect as much as possible what is expected from
IO::Socket::sysread and not what the SSL_read documentation says.

> Not anything using IO::Socket::SSL, I'm afraid.  I'm personally more
> used to the lower-level APIs like libssl and Net::SSLeay.  For libssl in
> particular, a quick codesearch returns a few prominent programs that
> reverted the new OpenSSL default.

For applications using lower level libraries it is perfectly fine to follow
changes in the behavior in these lower level libraries. The idea behind
higher level abstractions is that this does not need to be done, i.e. it
should hide lower level implementation details and just continue to work. It
is not always possible but at least one can try.

> Anyway this bug can probably be closed now, maybe we should follow up
> elsewhere.  Thanks for the discussion & analysis!

Thank You too. Regards,
Steffen