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

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



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

2018-08-24 Thread Kurt Roeckx
On Fri, Aug 24, 2018 at 10:27:16AM +, 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.


Kurt



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

2018-08-24 Thread Damyan Ivanov
-=| 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?


-- dam



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

2018-08-23 Thread Kurt Roeckx
On Thu, Aug 23, 2018 at 10:32:13PM +0200, Kurt Roeckx wrote:
> 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.

OpenSSL might only be able to handle the EPIPE case, and the
applications might need to handle the signal.


Kurt



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

2018-08-23 Thread Kurt Roeckx
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.