Bug#954371: [Pkg-openssl-devel] Bug#954371: Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
Control: reassign -1 libio-socket-ssl-perl 2.067-1 Control: severity -1 important Hi, On Wed, Apr 01, 2020 at 08:40:05PM +0200, Sebastian Andrzej Siewior wrote: > On 2020-03-31 21:49:51 [+0200], Salvatore Bonaccorso wrote: > > Hi Kurt, > Hi Salvatore, > > > I see, but then I prefer to loop in Steffen Ullrich into the loop > > (upstream of IO::Socket::SSL). Steffen, see the above comment from > > Kurt in the Debian bug, so it looks we cannot close > > https://github.com/noxxi/p5-io-socket-ssl/issues/93 by marking 1.1.1e > > as broken only. What do you think? > > we have openssl f in unstable so the visibile problem is gone for now. > Can this bug be assigned back to libio-socket-ssl-perl? Okay let's do that. Steffen Any comment on Kurt's hints in https://bugs.debian.org/954371#42? Regards, Salvatore
Processed: Re: Bug#954371: [Pkg-openssl-devel] Bug#954371: Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
Processing control commands: > reassign -1 libio-socket-ssl-perl 2.067-1 Bug #954371 [src:openssl] libio-socket-ssl-perl: FTBFS since openssl 1.1.1e Bug reassigned from package 'src:openssl' to 'libio-socket-ssl-perl'. No longer marked as found in versions openssl/1.1.1e-1. Ignoring request to alter fixed versions of bug #954371 to the same values previously set Bug #954371 [libio-socket-ssl-perl] libio-socket-ssl-perl: FTBFS since openssl 1.1.1e Marked as found in versions libio-socket-ssl-perl/2.067-1. > severity -1 important Bug #954371 [libio-socket-ssl-perl] libio-socket-ssl-perl: FTBFS since openssl 1.1.1e Severity set to 'important' from 'serious' -- 954371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#954371: [Pkg-openssl-devel] Bug#954371: Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
On 2020-03-31 21:49:51 [+0200], Salvatore Bonaccorso wrote: > Hi Kurt, Hi Salvatore, > I see, but then I prefer to loop in Steffen Ullrich into the loop > (upstream of IO::Socket::SSL). Steffen, see the above comment from > Kurt in the Debian bug, so it looks we cannot close > https://github.com/noxxi/p5-io-socket-ssl/issues/93 by marking 1.1.1e > as broken only. What do you think? we have openssl f in unstable so the visibile problem is gone for now. Can this bug be assigned back to libio-socket-ssl-perl? > Regards, > Salvatore Sebastian
Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
On Tue, Mar 31, 2020 at 11:48:26PM +0200, Steffen Ullrich wrote: > > You should fix your tests not to trigger an unexpected EOF. You > > probably have code now that ignores the current error, you > > shouldn't ignore that error, it's a real error. > > Fixing the tests to only consider an ideal world of nicely behaving peers is > in my opinion the wrong way to go. Instead I think that it is very useful > to have tests which include bad behaved peers since such peers are > unfortunately a reality. And it would be good if IO::Socket::SSL would > provide a defined and stable behavior in such situations and that the tests > check this. As for how this behavior should exactly look like I'm not fully > sure yet and I have to figure this out before OpenSSL 3.0.0 gets released. I do agree that testing for errors is important. I assumed that some tests failed because they ignored the error, but I guess they can also fail because they a different error than the one they expected. Kurt
Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
> You should fix your tests not to trigger an unexpected EOF. You > probably have code now that ignores the current error, you > shouldn't ignore that error, it's a real error. Fixing the tests to only consider an ideal world of nicely behaving peers is in my opinion the wrong way to go. Instead I think that it is very useful to have tests which include bad behaved peers since such peers are unfortunately a reality. And it would be good if IO::Socket::SSL would provide a defined and stable behavior in such situations and that the tests check this. As for how this behavior should exactly look like I'm not fully sure yet and I have to figure this out before OpenSSL 3.0.0 gets released. But in any case I rather have the tests fail early (like they also failed with Python and Ruby) when OpenSSL changes behavior in edge cases than have the users code fail somewhere later in production. Regards, Steffen -- Steffen Ullrich Research, Projects and Products steffen_ullr...@genua.de PGP 0x3F84B1A6F7DEAF80 genua GmbH Domagkstrasse 7, 85551 Kirchheim bei Muenchen tel +49 89 991950-0, fax -999, www.genua.de Geschaeftsfuehrer: Matthias Ochs, Marc Tesch Amtsgericht Muenchen HRB 98238 genua ist ein Unternehmen der Bundesdruckerei-Gruppe.
Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
On Tue, Mar 31, 2020 at 09:49:51PM +0200, Salvatore Bonaccorso wrote:
> Hi Kurt,
>
> On Tue, Mar 31, 2020 at 06:46:44PM +0200, Kurt Roeckx wrote:
> > On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> > > On Sat, Mar 21, 2020 at 08:31:21PM +0100, gregor herrmann wrote:
> > > > On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
> > > >
> > > > > The package FTBFS since openssl has been updated to 1.1.1e because the
> > > > > testsuite fails. The failure is due to commit db943f43a60d ("Detect
> > > > > EOF
> > > > > while reading in libssl") [0] in openssl. There an issue ticket [1]
> > > > > which introduced the changed behaviour.
> > > >
> > > > There's a patch at
> > > > https://github.com/noxxi/p5-io-socket-ssl/issues/93
> > > > This also needs libnet-ssleay-perl_1.88-3 which I uploaded right now.
> > >
> > > So I guess this should be threated as openssl issue and will reassign
> > > it to it. Upstream for IO::Socket::SSL has released a new version
> > > which will refuse to build with 1.1.1e:
> > >
> > > 2.068 2020/03/31
> > > - treat OpenSSL 1.1.1e as broken and refuse to build with it in order to
> > > prevent follow-up problems in tests and user code
> > > https://github.com/noxxi/p5-io-socket-ssl/issues/93
> > > https://github.com/openssl/openssl/issues/11388
> > > https://github.com/openssl/openssl/issues/11378
> >
> > There might be a misunderstanding. First, in 3.0, we will
> > reintroduce this new behaviour.
> >
> > We always returned an error in case of an unexpected EOF. We
> > changed the error code of that case. Applications should never
> > trigger the unexpected EOF and should get fixed not to trigger it.
>
> I see, but then I prefer to loop in Steffen Ullrich into the loop
> (upstream of IO::Socket::SSL). Steffen, see the above comment from
> Kurt in the Debian bug, so it looks we cannot close
> https://github.com/noxxi/p5-io-socket-ssl/issues/93 by marking 1.1.1e
> as broken only. What do you think?
If only https://github.com/openssl/openssl/issues/11388 is a
problem, I think only marking 1.1.1e as a problem is fine. But you
also point to https://github.com/openssl/openssl/issues/11378, which
talks about many different things, and the current plan is to
change back to that behaviour in 3.0. That is, react to an
unexpected EOF as the error it is, including the different error
code and marking the session as not reusable.
You should fix your tests not to trigger an unexpected EOF. You
probably have code now that ignores the current error, you
shouldn't ignore that error, it's a real error.
This might also affect reverse dependecies. And they need to get
fixed too.
Kurt
Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
Hi Kurt,
On Tue, Mar 31, 2020 at 06:46:44PM +0200, Kurt Roeckx wrote:
> On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> > On Sat, Mar 21, 2020 at 08:31:21PM +0100, gregor herrmann wrote:
> > > On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
> > >
> > > > The package FTBFS since openssl has been updated to 1.1.1e because the
> > > > testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> > > > while reading in libssl") [0] in openssl. There an issue ticket [1]
> > > > which introduced the changed behaviour.
> > >
> > > There's a patch at
> > > https://github.com/noxxi/p5-io-socket-ssl/issues/93
> > > This also needs libnet-ssleay-perl_1.88-3 which I uploaded right now.
> >
> > So I guess this should be threated as openssl issue and will reassign
> > it to it. Upstream for IO::Socket::SSL has released a new version
> > which will refuse to build with 1.1.1e:
> >
> > 2.068 2020/03/31
> > - treat OpenSSL 1.1.1e as broken and refuse to build with it in order to
> > prevent follow-up problems in tests and user code
> > https://github.com/noxxi/p5-io-socket-ssl/issues/93
> > https://github.com/openssl/openssl/issues/11388
> > https://github.com/openssl/openssl/issues/11378
>
> There might be a misunderstanding. First, in 3.0, we will
> reintroduce this new behaviour.
>
> We always returned an error in case of an unexpected EOF. We
> changed the error code of that case. Applications should never
> trigger the unexpected EOF and should get fixed not to trigger it.
I see, but then I prefer to loop in Steffen Ullrich into the loop
(upstream of IO::Socket::SSL). Steffen, see the above comment from
Kurt in the Debian bug, so it looks we cannot close
https://github.com/noxxi/p5-io-socket-ssl/issues/93 by marking 1.1.1e
as broken only. What do you think?
Regards,
Salvatore
Bug#954371: [Pkg-openssl-devel] Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
On Tue, Mar 31, 2020 at 09:03:01AM +0200, Salvatore Bonaccorso wrote:
> On Sat, Mar 21, 2020 at 08:31:21PM +0100, gregor herrmann wrote:
> > On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
> >
> > > The package FTBFS since openssl has been updated to 1.1.1e because the
> > > testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> > > while reading in libssl") [0] in openssl. There an issue ticket [1]
> > > which introduced the changed behaviour.
> >
> > There's a patch at
> > https://github.com/noxxi/p5-io-socket-ssl/issues/93
> > This also needs libnet-ssleay-perl_1.88-3 which I uploaded right now.
>
> So I guess this should be threated as openssl issue and will reassign
> it to it. Upstream for IO::Socket::SSL has released a new version
> which will refuse to build with 1.1.1e:
>
> 2.068 2020/03/31
> - treat OpenSSL 1.1.1e as broken and refuse to build with it in order to
> prevent follow-up problems in tests and user code
> https://github.com/noxxi/p5-io-socket-ssl/issues/93
> https://github.com/openssl/openssl/issues/11388
> https://github.com/openssl/openssl/issues/11378
There might be a misunderstanding. First, in 3.0, we will
reintroduce this new behaviour.
We always returned an error in case of an unexpected EOF. We
changed the error code of that case. Applications should never
trigger the unexpected EOF and should get fixed not to trigger it.
Kurt
Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
Control: reassign 954371 src:openssl 1.1.1e-1
Control: affects 954371 + libio-socket-ssl-perl
Hi,
On Sat, Mar 21, 2020 at 08:31:21PM +0100, gregor herrmann wrote:
> On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
>
> > The package FTBFS since openssl has been updated to 1.1.1e because the
> > testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> > while reading in libssl") [0] in openssl. There an issue ticket [1]
> > which introduced the changed behaviour.
>
> There's a patch at
> https://github.com/noxxi/p5-io-socket-ssl/issues/93
> This also needs libnet-ssleay-perl_1.88-3 which I uploaded right now.
So I guess this should be threated as openssl issue and will reassign
it to it. Upstream for IO::Socket::SSL has released a new version
which will refuse to build with 1.1.1e:
2.068 2020/03/31
- treat OpenSSL 1.1.1e as broken and refuse to build with it in order to
prevent follow-up problems in tests and user code
https://github.com/noxxi/p5-io-socket-ssl/issues/93
https://github.com/openssl/openssl/issues/11388
https://github.com/openssl/openssl/issues/11378
- update PublicSuffix with latest data from publicsuffix.org
Regards,
Salvatore
Processed: Re: Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
Processing control commands: > reassign 954371 src:openssl 1.1.1e-1 Bug #954371 [libio-socket-ssl-perl] libio-socket-ssl-perl: FTBFS since openssl 1.1.1e Bug reassigned from package 'libio-socket-ssl-perl' to 'src:openssl'. No longer marked as found in versions libio-socket-ssl-perl/2.067-1. Ignoring request to alter fixed versions of bug #954371 to the same values previously set Bug #954371 [src:openssl] libio-socket-ssl-perl: FTBFS since openssl 1.1.1e Marked as found in versions openssl/1.1.1e-1. > affects 954371 + libio-socket-ssl-perl Bug #954371 [src:openssl] libio-socket-ssl-perl: FTBFS since openssl 1.1.1e Added indication that 954371 affects libio-socket-ssl-perl -- 954371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
On Fri, 20 Mar 2020 21:50:08 +0100, Sebastian Andrzej Siewior wrote:
> The package FTBFS since openssl has been updated to 1.1.1e because the
> testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
> while reading in libssl") [0] in openssl. There an issue ticket [1]
> which introduced the changed behaviour.
There's a patch at
https://github.com/noxxi/p5-io-socket-ssl/issues/93
This also needs libnet-ssleay-perl_1.88-3 which I uploaded right now.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Beatles
signature.asc
Description: Digital Signature
Bug#954371: libio-socket-ssl-perl: FTBFS since openssl 1.1.1e
Package: libio-socket-ssl-perl
Version: 2.067-1
Severity: serious
The package FTBFS since openssl has been updated to 1.1.1e because the
testsuite fails. The failure is due to commit db943f43a60d ("Detect EOF
while reading in libssl") [0] in openssl. There an issue ticket [1]
which introduced the changed behaviour.
[0] https://github.com/openssl/openssl/pull/10882
[1] https://github.com/openssl/openssl/issues/10880
Sebastian
