-=| 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 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
-=| 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
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
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.
On 2018-04-18 00:16:41 [+0200], To sub...@bugs.debian.org wrote:
> There is openssl 1.1.1-pre4 in experimental right now and
> libnet-ssleay-perl fails the testsuite with it.
The complete buildlog
On Wed, Apr 18, 2018 at 09:46:06PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-04-18 16:14:37 [+0200], Kurt Roeckx wrote:
> > I can't see a reason why TLS 1.3 would be different in this regard,
> > I expect the same behaviour for all SSL/TLS version. Anyway, it
> > could just have been some
On 2018-04-18 16:14:37 [+0200], Kurt Roeckx wrote:
> I can't see a reason why TLS 1.3 would be different in this regard,
> I expect the same behaviour for all SSL/TLS version. Anyway, it
> could just have been some code refactor that "fixed" it so that it
> generates the error now. Or maybe the
On Wed, Apr 18, 2018 at 01:48:48PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-04-18 09:19:28 [+0200], Kurt Roeckx wrote:
>
> > Anyway, this might have been a bugfix in OpenSSL, which I think
> > how would get fixed in all branches.
>
> Oh. In that case it might end up in 1.0.2 which could
On 2018-04-18 09:19:28 [+0200], Kurt Roeckx wrote:
> On Wed, Apr 18, 2018 at 12:16:41AM +0200, Sebastian Andrzej Siewior wrote:
> >
> > The next thing is that step 24 within 07_sslecho.t blocks forever. As it
> > turns out one side does "shutdown $s, 2;" (around line 170) while the
> > other does
On Wed, Apr 18, 2018 at 12:16:41AM +0200, Sebastian Andrzej Siewior wrote:
>
> The next thing is that step 24 within 07_sslecho.t blocks forever. As it
> turns out one side does "shutdown $s, 2;" (around line 170) while the
> other does a read+write operation. In "older" openssl is seems to just
Package: libnet-ssleay-perl
Version: 1.85-1
Severity: important
There is openssl 1.1.1-pre4 in experimental right now and
libnet-ssleay-perl fails the testsuite with it. I was playing with it
for the last month or so and already figured out a few things. This is
t/local/07_sslecho.t I refer here
12 matches
Mail list logo
