The new openssl 1.1.1 is currently in experimental . This package
failed to build against this new package  while it built fine against
the openssl version currently in unstable .
Could you please have a look?
The Error in the testsuite could be due to:
| * 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.
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.
> 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.