Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1
-=| Kurt Roeckx, 24.08.2018 18:52:57 +0200 |=- > On Fri, Aug 24, 2018 at 10:27:16AM +, Damyan Ivanov wrote: > > -=| Kurt Roeckx, 23.08.2018 22:32:13 +0200 |=- > > > Note that the SIGPIPE issue is probably a known upstream issue > > > that still needs to be fixed, we're at least still working on a > > > SIGPIPE issue. > > > > > > But that does not mean that the other issues in libnet-ssleay-perl > > > should not get fixed. > > > > I tried applying all the patches from the fedora package of > > Net-SSLeay, and it didn't help much. > > > > It was mentioned in the upstream ticket that an additional fix is > > needed on libssl side, see > > https://bugzilla.redhat.com/show_bug.cgi?id=1615098 > > > > The reproducer from there fails with 1.1.1~~pre9-1 from unstable. > > > > Does this seem like something that needs to be fixed on the openssl > > side? > > This is something that should get fixed in whatever calls > TLSv1_method(). You should never call that function. It's also > been deprecated. > > The problem is that TLSv1_method() only supports TLS 1.0, and the > default config now says that TLS 1.2 is the minimum verison. You > should either use SSLv23_method() or TLS_method(), which support all > protocol versions that are enabled. I worked around this in Net::SSLeay by patching the routine that sets certificate and key to return an error condition only if any of the underlying routines return an error condition (https://salsa.debian.org/perl-team/modules/packages/libnet-ssleay-perl/blob/master/debian/patches/ok-result-is-no-error.patch). Previously it would check the error stack and ignore the return codes. On a more general note, the package seems ready for unstable to me. Reviews are welcome. If no obstacles appear, I plan to upload on late Sunday. -- dam
Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1
On Fri, Aug 24, 2018 at 10:27:16AM +, Damyan Ivanov wrote: > -=| Kurt Roeckx, 23.08.2018 22:32:13 +0200 |=- > > Note that the SIGPIPE issue is probably a known upstream issue > > that still needs to be fixed, we're at least still working on a > > SIGPIPE issue. > > > > But that does not mean that the other issues in libnet-ssleay-perl > > should not get fixed. > > I tried applying all the patches from the fedora package of > Net-SSLeay, and it didn't help much. > > It was mentioned in the upstream ticket that an additional fix is > needed on libssl side, see > https://bugzilla.redhat.com/show_bug.cgi?id=1615098 > > The reproducer from there fails with 1.1.1~~pre9-1 from unstable. > > Does this seem like something that needs to be fixed on the openssl > side? This is something that should get fixed in whatever calls TLSv1_method(). You should never call that function. It's also been deprecated. The problem is that TLSv1_method() only supports TLS 1.0, and the default config now says that TLS 1.2 is the minimum verison. You should either use SSLv23_method() or TLS_method(), which support all protocol versions that are enabled. Kurt
Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1
-=| Kurt Roeckx, 23.08.2018 22:32:13 +0200 |=- > Note that the SIGPIPE issue is probably a known upstream issue > that still needs to be fixed, we're at least still working on a > SIGPIPE issue. > > But that does not mean that the other issues in libnet-ssleay-perl > should not get fixed. I tried applying all the patches from the fedora package of Net-SSLeay, and it didn't help much. It was mentioned in the upstream ticket that an additional fix is needed on libssl side, see https://bugzilla.redhat.com/show_bug.cgi?id=1615098 The reproducer from there fails with 1.1.1~~pre9-1 from unstable. Does this seem like something that needs to be fixed on the openssl side? -- dam
Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1
On Thu, Aug 23, 2018 at 10:32:13PM +0200, Kurt Roeckx wrote: > Note that the SIGPIPE issue is probably a known upstream issue > that still needs to be fixed, we're at least still working on a > SIGPIPE issue. OpenSSL might only be able to handle the EPIPE case, and the applications might need to handle the signal. Kurt
Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1
Note that the SIGPIPE issue is probably a known upstream issue that still needs to be fixed, we're at least still working on a SIGPIPE issue. But that does not mean that the other issues in libnet-ssleay-perl should not get fixed.
Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp
On 2018-04-18 00:16:41 [+0200], To sub...@bugs.debian.org wrote: > There is openssl 1.1.1-pre4 in experimental right now and > libnet-ssleay-perl fails the testsuite with it. The complete buildlog https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/libnet-ssleay-perl_1.85-1_amd64-2018-05-01T20%3A22%3A35Z With pre6 there is an additional issue: |# Failed test 'set_cert_and_key: certificate `t/data/cert.pem' () 17762: 1 - error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small due to (1.1.1~~pre6-1 changelog): | * Increase default security level from 1 to 2. This moves from the 80 bit | security level to the 112 bit securit level and will require 2048 bit RSA | and DHE keys. Sebastian
Bug#895959: [Pkg-openssl-devel] Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp
On Wed, Apr 18, 2018 at 09:46:06PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-04-18 16:14:37 [+0200], Kurt Roeckx wrote:
> > I can't see a reason why TLS 1.3 would be different in this regard,
> > I expect the same behaviour for all SSL/TLS version. Anyway, it
> > could just have been some code refactor that "fixed" it so that it
> > generates the error now. Or maybe the old code generated an error
> > on SSL_write() instead of the SIGPIPE?
> >
> > It would at least be good to know how the old version behaved.
>
> As per bisect, openssl commit 30f05b19d3ba ("Create the NewSessionTicket
> message in TLSv1.3") is responsible for the SIGPIPE.
> But I *think* this is unrelated. The perl testcase triggers reliable. My
> C test case I used yestrday triggers only under strace (but I think this
> was not the case yesterday). So I *think* this commit changed the
> timming and now the SIGPIPE is more likely.
So if I understand things, the write now happes after the other
side does the shutdown(), while it happened before previously?
Anyway, it seems to me that they should use SSL_shutdown() before
closing the connection.
Kurt
Bug#895959: [Pkg-openssl-devel] Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp
On 2018-04-18 16:14:37 [+0200], Kurt Roeckx wrote:
> I can't see a reason why TLS 1.3 would be different in this regard,
> I expect the same behaviour for all SSL/TLS version. Anyway, it
> could just have been some code refactor that "fixed" it so that it
> generates the error now. Or maybe the old code generated an error
> on SSL_write() instead of the SIGPIPE?
>
> It would at least be good to know how the old version behaved.
As per bisect, openssl commit 30f05b19d3ba ("Create the NewSessionTicket
message in TLSv1.3") is responsible for the SIGPIPE.
But I *think* this is unrelated. The perl testcase triggers reliable. My
C test case I used yestrday triggers only under strace (but I think this
was not the case yesterday). So I *think* this commit changed the
timming and now the SIGPIPE is more likely.
> Kurt
Sebastian
Bug#895959: [Pkg-openssl-devel] Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp
On Wed, Apr 18, 2018 at 01:48:48PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-04-18 09:19:28 [+0200], Kurt Roeckx wrote: > > > Anyway, this might have been a bugfix in OpenSSL, which I think > > how would get fixed in all branches. > > Oh. In that case it might end up in 1.0.2 which could supprise people > which did not handle SIGPIPE earlier and now have to. But this piece > only showed up with tls1.3. I can't see a reason why TLS 1.3 would be different in this regard, I expect the same behaviour for all SSL/TLS version. Anyway, it could just have been some code refactor that "fixed" it so that it generates the error now. Or maybe the old code generated an error on SSL_write() instead of the SIGPIPE? It would at least be good to know how the old version behaved. Kurt
Bug#895959: [Pkg-openssl-devel] Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp
On 2018-04-18 09:19:28 [+0200], Kurt Roeckx wrote: > On Wed, Apr 18, 2018 at 12:16:41AM +0200, Sebastian Andrzej Siewior wrote: > > > > The next thing is that step 24 within 07_sslecho.t blocks forever. As it > > turns out one side does "shutdown $s, 2;" (around line 170) while the > > other does a read+write operation. In "older" openssl is seems to just > > work but in the newer one SIGPIPE is received and this seems to > > stall/block the test case. > > As far as I know "2" means to shut down both the read and write. correct. > The other side doing reads and writes seems strange to me. the other side does not know that. So it tries to write to the socket - nothing wrong about that. It looks however that libssl behaves differently and _now_ the SIGPIPE is seen which was not before. > Anyway, this might have been a bugfix in OpenSSL, which I think > how would get fixed in all branches. Oh. In that case it might end up in 1.0.2 which could supprise people which did not handle SIGPIPE earlier and now have to. But this piece only showed up with tls1.3. > Kurt Sebastian
Bug#895959: [Pkg-openssl-devel] Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp
On Wed, Apr 18, 2018 at 12:16:41AM +0200, Sebastian Andrzej Siewior wrote: > > The next thing is that step 24 within 07_sslecho.t blocks forever. As it > turns out one side does "shutdown $s, 2;" (around line 170) while the > other does a read+write operation. In "older" openssl is seems to just > work but in the newer one SIGPIPE is received and this seems to > stall/block the test case. As far as I know "2" means to shut down both the read and write. The other side doing reads and writes seems strange to me. Anyway, this might have been a bugfix in OpenSSL, which I think how would get fixed in all branches. Kurt
Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1 in exp
Package: libnet-ssleay-perl
Version: 1.85-1
Severity: important
There is openssl 1.1.1-pre4 in experimental right now and
libnet-ssleay-perl fails the testsuite with it. I was playing with it
for the last month or so and already figured out a few things. This is
t/local/07_sslecho.t I refer here to.
The SSL_read() and SSL_write() wrapper need to handle a possible retry.
The man-page for both function [0] says that it might need to be retried
with the same arguments. With the following hunk:
diff --git a/SSLeay.xs b/SSLeay.xs
--- a/SSLeay.xs
+++ b/SSLeay.xs
@@ -1999,7 +1999,17 @@ SSL_read(s,max=32768)
int got;
PPCODE:
New(0, buf, max, char);
- got = SSL_read(s, buf, max);
+
+ do {
+ int err;
+
+ got = SSL_read(s, buf, max);
+ if (got > 0)
+ break;
+ err = SSL_get_error(s, got);
+ if (err != SSL_ERROR_WANT_READ)
+ break;
+ } while (1);
/* If in list context, return 2-item list:
* first return value: data gotten, or undef on error (got<0)
@@ -2051,10 +2061,20 @@ SSL_write(s,buf)
SSL * s
PREINIT:
STRLEN len;
+ int err;
+ int ret;
INPUT:
char * buf = SvPV( ST(1), len);
CODE:
- RETVAL = SSL_write (s, buf, (int)len);
+ do {
+ret = SSL_write (s, buf, (int)len);
+if (ret > 0)
+break;
+err = SSL_get_error(s, ret);
+if (err != SSL_ERROR_WANT_WRITE)
+break;
+ } while (1);
+ RETVAL = ret;
OUTPUT:
RETVAL
@@ -2083,8 +2103,20 @@ SSL_write_partial(s,from,count,buf)
if (len < 0) {
croak("from beyound end of buffer");
RETVAL = -1;
- } else
- RETVAL = SSL_write (s, &(buf[from]), (count<=len)?count:len);
+ } else {
+int ret;
+int err;
+
+do {
+ret = SSL_write (s, &(buf[from]), (count<=len)?count:len);
+if (ret > 0)
+break;
+err = SSL_get_error(s, ret);
+if (err != SSL_ERROR_WANT_WRITE)
+break;
+} while (1);
+RETVAL = ret;
+ }
OUTPUT:
RETVAL
I was able to let the test-suite continue a little further. As per
upstream [1] this was always the case it worked by coincidence before.
The next thing is that step 24 within 07_sslecho.t blocks forever. As it
turns out one side does "shutdown $s, 2;" (around line 170) while the
other does a read+write operation. In "older" openssl is seems to just
work but in the newer one SIGPIPE is received and this seems to
stall/block the test case. By adding:
index 5e16b04b55ea..c60afccc0051 100644
--- a/t/local/07_sslecho.t
+++ b/t/local/07_sslecho.t
@@ -14,6 +14,7 @@ BEGIN {
}
plan tests => 78;
+$SIG{'PIPE'} = 'IGNORE';
my $sock;
my $pid;
(
it does not stall anymore but complains about the return value from
write:
ok 21 - get_cipher
ok 22 - get_shared_ciphers
ok 23 - ssl_read_all
not ok 24 - ssl_write_all
# Failed test 'ssl_write_all'
# at t/local/07_sslecho.t line 88.
ok 25 - new
This should be okay since the other side never reads anything and just
shutdowns the socket.
Could you please take a look and forward it upstream?
[0] https://manpages.debian.org/stretch/libssl-doc/SSL_read.3ssl.en.html#WARNING
[1] https://github.com/openssl/openssl/issues/5637#issuecomment-381364019
Sebastian
