Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
* Kurt Roeckx [2019-03-20 07:31]: > On Tue, Mar 19, 2019 at 11:21:19PM +0100, Holger Weiß wrote: > > * Kurt Roeckx [2019-03-19 22:59]: > > > On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote: > > > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ > > > > unexpectedly returns NULL. I now avoid the function to work around the > > > > issue. > > > > > > This is documented here: > > > https://wiki.openssl.org/index.php/TLS1.3#PSKs > > > > Thanks. I'm still using the TLSv1.2 callbacks indeed, but from reading > > that text it's not obvious to me why SSL_get_psk_identity() would fail. > > (Note that I'm not using identity *hints* anywhere, which is the thing > > TLSv1.3 dropped.) However, I can easily imagine the bug(?) being > > related to the changes mentioned in that text. > > If you think there is a bug, please file a bug on github. Done: https://github.com/openssl/openssl/issues/8534
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
On Tue, Mar 19, 2019 at 11:21:19PM +0100, Holger Weiß wrote: > * Kurt Roeckx [2019-03-19 22:59]: > > On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote: > > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ > > > unexpectedly returns NULL. I now avoid the function to work around the > > > issue. > > > > This is documented here: > > https://wiki.openssl.org/index.php/TLS1.3#PSKs > > Thanks. I'm still using the TLSv1.2 callbacks indeed, but from reading > that text it's not obvious to me why SSL_get_psk_identity() would fail. > (Note that I'm not using identity *hints* anywhere, which is the thing > TLSv1.3 dropped.) However, I can easily imagine the bug(?) being > related to the changes mentioned in that text. If you think there is a bug, please file a bug on github. Kurt
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
* Kurt Roeckx [2019-03-19 22:59]: > On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote: > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ > > unexpectedly returns NULL. I now avoid the function to work around the > > issue. > > This is documented here: > https://wiki.openssl.org/index.php/TLS1.3#PSKs Thanks. I'm still using the TLSv1.2 callbacks indeed, but from reading that text it's not obvious to me why SSL_get_psk_identity() would fail. (Note that I'm not using identity *hints* anywhere, which is the thing TLSv1.3 dropped.) However, I can easily imagine the bug(?) being related to the changes mentioned in that text.
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote: > Just for the record: > > * Sebastian Andrzej Siewior [2018-11-05 00:28]: > > It is a TLS1.3 issue. If I limit max protocol to TLS1.2 then the > > testsuite passes. > > Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ > unexpectedly returns NULL. I now avoid the function to work around the > issue. This is documented here: https://wiki.openssl.org/index.php/TLS1.3#PSKs Kurt
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
Just for the record: * Sebastian Andrzej Siewior [2018-11-05 00:28]: > It is a TLS1.3 issue. If I limit max protocol to TLS1.2 then the > testsuite passes. Yes, it's an OpenSSL bug. If TLSv1.3 is used, SSL_get_psk_identity()¹ unexpectedly returns NULL. I now avoid the function to work around the issue. ¹ https://www.openssl.org/docs/man1.1.1/man3/SSL_get_psk_identity.html
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
On Mon, Nov 05, 2018 at 12:28:50AM +0100, Sebastian Andrzej Siewior wrote: > > No, it is not. It is a TLS1.3 issue. If I limit max protocol to TLS1.2 > then the testsuite passes. The problem with TLS1.3 could be that > SSL_read() could return SSL_ERROR_WANT_READ asking to do the same. Was > there a workaround for this or do I mix up things? > Anyway, it seems that SSL_connect() returns SSL_ERROR_WANT_READ. I'm not sure if there actually changed something related to SSL_connect(), it could always return SSL_ERROR_WANT_READ, I expect it to return that for a non-blocking socket when it's waiting for the server hello. Or are you seeing it with a blocking socket? I can't think of a reason why that should have changed. Kurt
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
On 2018-05-26 23:35:46 [+0200], To sub...@bugs.debian.org wrote: > The Error in the testsuite could be 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. No, it is not. It is a TLS1.3 issue. If I limit max protocol to TLS1.2 then the testsuite passes. The problem with TLS1.3 could be that SSL_read() could return SSL_ERROR_WANT_READ asking to do the same. Was there a workaround for this or do I mix up things? Anyway, it seems that SSL_connect() returns SSL_ERROR_WANT_READ. Sebastian
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
* Sebastiaan Couwenberg [2018-08-23 07:13]: > Are you aware of this issue in NSCA-ng? No. > I did not find a link to a bugtracker on nsca-ng.org, so I'm forwarding > this by email. I've now enabled the issue tracker on GitHub; if you believe this to be an upstream bug, feel free to report it there: https://github.com/weiss/nsca-ng/issues/new Please note the exact OpenSSL version, and, if tests are failing, include the output of: sed /config.log/q tests/testsuite.log Thanks!
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
Hi Holger, Are you aware of this issue in NSCA-ng? I did not find a link to a bugtracker on nsca-ng.org, so I'm forwarding this by email. On Sat, 26 May 2018 23:35:46 +0200 Sebastian Andrzej Siewior wrote: > Source: nsca-ng > Version: 1.5-2 > Severity: important > User: pkg-openssl-de...@lists.alioth.debian.org > Usertags: openssl-1.1.1 > > The new openssl 1.1.1 is currently in experimental [0]. This package > failed to build against this new package [1] while it built fine against > the openssl version currently in unstable [2]. > Could you please have a look? > > The Error in the testsuite could be 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. > > [0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be > [1] > https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/nsca-ng_1.5-2_amd64-2018-05-01T20%3A31%3A09Z > [2] > https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/nsca-ng_1.5-2_amd64-2018-05-02T18%3A46%3A37Z > > Sebastian Kind Regards, Bas
Bug#900152: nsca-ng: FTBFS against openssl 1.1.1
Source: nsca-ng Version: 1.5-2 Severity: important User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-1.1.1 The new openssl 1.1.1 is currently in experimental [0]. This package failed to build against this new package [1] while it built fine against the openssl version currently in unstable [2]. Could you please have a look? The Error in the testsuite could be 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. [0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be [1] https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/nsca-ng_1.5-2_amd64-2018-05-01T20%3A31%3A09Z [2] https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/nsca-ng_1.5-2_amd64-2018-05-02T18%3A46%3A37Z Sebastian
