Bug#900152: nsca-ng: FTBFS against openssl 1.1.1

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#900152: nsca-ng: FTBFS against openssl 1.1.1

Sebastian Andrzej Siewior
Source: nsca-ng
Version: 1.5-2
Severity: important
User: [hidden email]
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.GA21460@...
[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

Reply | Threaded
Open this post in threaded view
|

Bug#900152: nsca-ng: FTBFS against openssl 1.1.1

Sebastian Andrzej Siewior
On 2018-05-26 23:35:46 [+0200], To [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Bug#900152: nsca-ng: FTBFS against openssl 1.1.1

Holger Weiß
In reply to this post by Sebastian Andrzej Siewior
* Kurt Roeckx <[hidden email]> [2019-03-20 07:31]:

> On Tue, Mar 19, 2019 at 11:21:19PM +0100, Holger Weiß wrote:
> > * Kurt Roeckx <[hidden email]> [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