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