Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1

[Damyan Ivanov]

-=| Kurt Roeckx, 24.08.2018 18:52:57 +0200 |=-
> On Fri, Aug 24, 2018 at 10:27:16AM +0000, 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