On 2020-03-26 23:57:24 [-0400], Sandro Tosi wrote:
> > So the test expects no error. Since the commit mention there is an
> > error where earlier there was none. From the Changes file:
> >
> > | *) Properly detect EOF while reading in libssl. Previously if we hit an
> > EOF
> > | while reading in libssl then we would report an error back to the
> > | application (SSL_ERROR_SYSCALL) but errno would be 0. We now add
> > | an error to the stack (which means we instead return SSL_ERROR_SSL) and
> > | therefore give a hint as to what went wrong.
> >
> > OpenSSL 1.1.1d with the commit question leads to this behaviour.
>
> isnt this a regression in openssl then? why there's no RC bug filed
> against openssl and you filed this bug against a downstream package?
> i'm still not clear what you expect us to do with regards to m2crypto:
> should we skip the failing test?
The situation is a bit complicated as it seems. The EOF condition
was not properly detected by openssl. Now it does (and sets an error
code) and applications fail (including this test case I'm not not sure
how the application behaves). It appears that there are also poorly
implemented Web servers [0] leading to other problems.
I will downgrade the bug's severity because this change is reverted in
openssl 1.1.1 stable series:
https://github.com/openssl/openssl/commit/0cd2ee64bffcdece599c3e4b5fac3830a55dc0fa
If I'm not fast enough, feel free to downgrade it yourself. This change
will come back in 3.0 series of openssl (that is why I'm not closing it).
[0] https://github.com/openssl/openssl/issues/11378
Sebastian
