There might be a related change that doesn't allow restarting the operation
with the same context without setting things up again.
Hi,
Is the issue that with older glibc versions, it was silently casted
to a 32 bit value, but now that glibc supports 64 bit, it knows
it can't represent it, and gives an error?
Maybe for bookworm, we should just ignore the test error?
Kurt
Hi,
Are you waiting for something before uploading this fix?
Kurt
Hi,
It seems a fix for this is sitting git, but hasn't been uploaded. Is
there a reason it's not been uploaded yet?
Kurt
Source: aflplusplus
Version: 4.04c-2
Severity: serious
Hi,
Your package is failing to build on s390x:
[*] Compiling afl++ for OS Linux on ARCH s390x
./test/unittests/unit_maybe_alloc
[==] Running 6 test(s).
[ RUN ] test_pow2
[ OK ] test_pow2
[ RUN ] test_null_allocs
[
Source: aflplusplus
Version: 4.04c-1
Severity: serious
Hi,
On the buildds, we get:
# -/usr/bin/make -C utils/plot_ui
/usr/bin/make -C frida_mode
make[3]: Entering directory '/<>/frida_mode'
mkdir -p /<>/frida_mode/build/
mkdir -p /<>/frida_mode/build/frida/
wget -qO
fasttrack contains a 1.7.3 version that's new enough. The 1.8.0 version
from backports is too new it seems, and it what gets installed when
you just do: apt install gitlab
Package: gitlab
Version: 15.4.2+ds1-1~fto11+3
Severity: serious
Setting up gitlab (15.4.2+ds1-1~fto11+3) ...
Bundler could not find compatible versions for gem "omniauth-oauth2":
In Gemfile:
omniauth-auth0 (~> 2.0) was resolved to 2.0.0, which depends on
omniauth-oauth2 (~> 1.4)
On Sun, Sep 25, 2022 at 02:16:00AM +, Thorsten Glaser wrote:
> Kurt Roeckx dixit:
>
> >On Sat, Sep 24, 2022 at 10:34:19PM +0200, Thorsten Glaser wrote:
> >> $ openssl s_client -CApath /etc/ssl/certs -connect www.mirbsd.org:443
> >> -legacy_renegotiation -tls1
&
Source: nvidia-cuda-toolkit
Version: 11.4.3-2
Severity: serious
Tags: sid bookworm
Hi,
It seems build-depends on libssl1.1 and not on libssl-dev. It also
depends on libssl1.1 and doesn't transition to libssl3 on rebuild.
Can you please move to using libssl3?
Kurt
Source: thrift
Version: 0.16.0-5
Severity: serious
Tags: sid bookworm
Hi,
It seems that thrift does not depend on libssl after being rebuild
against OpenSSL 3.0, but did depend on libssl1.1.
Kurt
It looks like it's fixed here: https://github.com/openssl/openssl/pull/18247
On Wed, May 11, 2022 at 07:25:45PM +0300, Andriy Grytsenko wrote:
> >You can test it by installing the version from unstable.
>
> It is not in unstable yet, see
That should have said experimental.
Kurt
tags 996276 - bookworm-ignore experimental + bookworm sid
thanks
This is affecting the bookworm release. The release managers approved the
upload to unstable and marked it as serious/release critical.
You can test it by installing the version from unstable.
It seems that 6.4.23 actually changed the message to:
configuration requires TLS, but STARTTLS is not permitted because of
authenticated state (PREAUTH). Aborting connection. If your plugin is secure,
you can defeat STARTTLS with --sslproto '' (see manual).
See:
Package: fetchmail
Version: 6.4.22-1
Severity: serious
Hi,
With version 6.4.22-1 and 6.4.23-1 I get the following error:
configuration requires TLS, but STARTTLS is not permitted because of
authenticated state (PREAUTH). Aborting connection. Server permitting, try
--ssl instead (see manual).
On Mon, Oct 18, 2021 at 10:40:59PM +0200, Julien Cristau wrote:
> On Mon, Oct 18, 2021 at 02:50:50PM +0200, Benjamin Hof wrote:
> > Hi,
> >
> > I think the following change might be the relevant one:
> >
> > --- a/update-ca-certificates
> > +++ b/update-ca-certificates
> > @@ -164,8
Package: lbeibiou
Version: 3.61.2-1
Severity: serious
Hi,
During an upgrade, I get the following:
dpkg: considering deconfiguration of lebiniou-data, which would be broken by
installation of lebiniou ...
dpkg: yes, will deconfigure lebiniou-data (broken by lebiniou)
Preparing to unpack
reassign 990228 ssl-cert
severity 990228 normal
thanks
So I think there is no bug in OpenSSL and the additional check
being done in 3.0 makes sense. So I'm reassigning this to
ssl-cert.
Kurt
On Thu, Jun 24, 2021 at 12:20:45AM +0200, Kurt Roeckx wrote:
>
> From the manpage:
>Random State Options
>
>Prior to OpenSSL 1.1.1, it was common for applications to store
>information about the state of the random-number generator in a
>file that
On Wed, Jun 23, 2021 at 09:05:03PM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-06-23 14:46:37 [+0200], Andreas Beckmann wrote:
> > Writing new private key to '/etc/ssl/private/ssl-cert-snakeoil.key'
> > -
> > Warning: No -copy_extensions given; ignoring any extensions in the
forwarded 983013 https://gitlab.com/m2crypto/m2crypto/-/issues/293
thanks
I've created an upstream issue for it.
reopen 977657
thanks
Hi,
The CI test still fails with 1.1.1i:
Testing package ssl:ssl
Script test_ssl.pl failed: Unknown message: exit(1)
% PL-Unit: ssl_options ... done
% PL-Unit: ssl_server . done
% PL-Unit: ssl_keys . done
% PL-Unit: ssl_certificates .
Package: swi-prolog
Version: 8.2.3+dfsg-1
Severity: serious
Forwarded: https://github.com/SWI-Prolog/packages-ssl/issues/159
Tag: patch
Hi,
Swi-prolog is failing to build using OpenSSL 1.1.1i. I've attached
a patch that fixes it.
Kurt
--- packages/ssl/test_ssl.pl.orig 2020-12-18
Package: m2crypto
Version: 0.36.0-1
Severity: serious
Forwarded: https://gitlab.com/m2crypto/m2crypto/-/issues/289
Hi,
m2crypto is failing to build since the 1.1.1i version of OpenSSL,
see the upstream bug report for more details.
Kurt
On Sat, Dec 05, 2020 at 02:13:32PM +0100, Matthias Klose wrote:
> Package: src:openssl
> Version: 1.1.1h-1
> Severity: serious
> Tags: sid bullseye patch
>
> Please backport https://github.com/openssl/openssl/pull/13585
>
> Without this patch, this causes python-asyncssh's tests to fail (and
On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote:
> On Fri, Nov 6, 2020 at 9:09 AM Michal Palenik wrote:
> > for those stumbling on this via searching, the workaround mentioned
> > above is:
> [...]
> > apt -t unstable install libssl1.1:amd64
> Thanks for possibly the
Package: swi-prolog
Version: 8.2.1+dfsg-2
Severity: serious
Hi,
swi-prolog fails to build using OpenSSL 1.1.1h. See
https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/7715788/log.gz
for a log.
I've filed an upstream bug about this at:
Just to clarify, as I understand it, openssl 1.0.2 (so libssl1.0.2
in oldstable) still has the problem, which means things like
libcurl in oldstable have that problem. And removing the
certificate from the trust store fixes it.
Kurt
On Mon, Jun 01, 2020 at 01:29:39AM +0200, Axel Beckert wrote:
> OpenSSL 1.1.1g 21 Apr 2020
> → openssl s_client -connect mirror.sinavps.ch:443
> CONNECTED(0003)
> depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN =
> AddTrust External CA Root
> verify
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
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 +010
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
> > >
Package: rng-tools
Version: 5-1
Severity: serious
I tried to upgrade from 2-unofficial-mt.14-1+b2 to 5-1, but
installation failed because --feed-interval and --rng-entropy
are no longer supported.
It's non-trivial to found out what the problem is, no error message
is logged or displayed on the
Package: unbound
Version: 1.9.6-1
Severity: serious
Hi,
After upgrade to 1.9.6-1, unbound did no longer start. It did not
log anything about this in any log file.
I have a config that says:
do-not-query-localhost: no
It now returns a syntax error for that.
Kurt
On Tue, Sep 17, 2019 at 08:32:28AM +0200, Sebastian Andrzej Siewior wrote:
> Package: python-cryptography
> Version: 2.6.1-3
> Severity: serious
>
> The upload of latest openssl 1.1.1d triggert three testsuite failures in
> python-cryptography [0]
>
> - _
On Tue, Jun 04, 2019 at 02:24:12PM +0200, Matěj Cepl wrote:
> Sebastian Andrzej Siewior píše v Út 04. 06. 2019 v 14:15 +0200:
> > Let me ping upstream: Matěj, could you please take a look at
> > https://bugs.debian.org/929903
> >
> > and check if it is okay the test no longer fails or if
On Tue, Jun 04, 2019 at 12:46:07AM +0200, Sebastian Andrzej Siewior wrote:
>
> So if I decoded it right, it does
>
> | fbuf = sha1("The magic words are squeamish ossifrage."); /* 0xbf, 0xf0,
> 0x04 … */
> | flen = RSA_public_encrypt(20, fbuf, tobuf, )
> | /* flen -> 128 */
> | r
t; | Fix memory overrun in rsa padding check functions
> |
> | Fixes #8364 and #8357
> |
> | Reviewed-by: Kurt Roeckx
> | (Merged from https://github.com/openssl/openssl/pull/8365)
> |
> | (cherry picked from commit d7f5e5ae6d53f1387a42d210806cf5e9ed0882d6)
>
On Tue, Mar 19, 2019 at 11:21:19PM +0100, Holger Weiß wrote:
> * Kurt Roeckx [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
On Tue, Mar 19, 2019 at 10:28:06PM +0100, Holger Weiß wrote:
> Just for the record:
>
> * Sebastian Andrzej Siewior [2018-11-05 00:28]:
> > It is a TLS1.3 issue. If I limit max protocol to TLS1.2 then the
> > testsuite passes.
>
> Yes, it's an OpenSSL bug. If TLSv1.3 is used,
On Sun, Mar 10, 2019 at 02:20:45PM +, Steve McIntyre wrote:
> Hi!
>
> I don't know if you've even seen this RC bug. Could you please update
> the maintainer address to point to something that works?
I never got an email to the -owner address, so I couldn't migrate
it. I assume our CVS
Package: wml
Version: 2.12.2~ds1-1
Severity: serious
Hi,
I'm getting the following error:
Can't locate GD.pm in @INC (you may need to install the GD module) (@INC
contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1
/usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28
Package: python3-twisted
Version: 17.4.0-2
Severity: serious
Hi,
When using python3-twisted from backports (18.7.0-2~bpo9+1), I get
the following error:
Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File
On Sat, Jan 19, 2019 at 12:24:45PM +0300, sergio wrote:
> On Fri, 18 Jan 2019 23:02:28 +0100 Kurt Roeckx wrote:
>
> > You have python3-msgpack (>= 0.3.0), while it should be be >= 0.4.2.
>
>
> The python3-msgpack dependency is absent.
>
> % apt s
On Fri, Jan 18, 2019 at 10:34:36PM +0100, Andrej Shadura wrote:
> Hi,
>
> On Fri, 18 Jan 2019 at 22:15, Kurt Roeckx wrote:
> > On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> > > found 919707 0.34.1.1-2~bpo9+1
> > > notfound 919707 0.34.1.1-2
&
On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> found 919707 0.34.1.1-2~bpo9+1
> notfound 919707 0.34.1.1-2
I believe the version I've set it to was the correct version, even
when I did find the problem in backports, the problem really exist
is both testing and
Package: matrix-synapse
Version: 0.34.1.1-2
Severity: serious
Hi,
When installing the version in stretch-backports, I get:
-- Unit matrix-synapse.service has begun starting up.
Jan 18 19:07:18 mirror python3[25438]: ERROR:root:Needed pymacaroons>=0.9.3,
got pymacaroons==0.9.2
Jan 18 19:07:18
I've enabled guile-2.0 and 2.2 again on armel yesterday, and it
seems to build without issues now.
Source: gnucash
Version: 1:3.3-2
Severity: serious
Gnucash has a test suite problem. There is a log here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gnucash.html
showing:
[pass] line:641, test: dual amount column, grand totals available
[fail] line:644, test: dual amount
Package: python-twisted-core
Version: 18.7.0-2~bpo9+1
Severity: serious
Hi,
With python-twisted-core and python-attr 16.3.0-1, I get the
following error:
[...]
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 100, in
from twisted.internet import interfaces, protocol,
On Sun, Dec 02, 2018 at 11:36:06PM +0100, gregor herrmann wrote:
> On Sun, 02 Dec 2018 23:18:38 +0100, Sebastian Andrzej Siewior wrote:
>
> > On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
> > > #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
> > > ruby-eventmachine
On Wed, Nov 28, 2018 at 02:35:42PM +, Christoph Groth wrote:
> My mbsync (isync package) setup stopped working for a particular IMAP server
> because of this bug. I get the following error message:
>
> Socket error: secure connect to imap.server.com (1.2.3.4:993):
> error:141A318A:SSL
Source: kde4libs
Version: 4:4.14.38-2
Severity: serious
Hi,
It seems that kde4libs Build-Depends on libssl1.0-dev as a result
of #828363. There are currently no packages depending on
libssl1.0.2 left in testing, but this source package is the only
one that has a Build-Depends against
On Sat, Nov 10, 2018 at 03:48:37PM +0100, Pino Toscano wrote:
> In data sabato 10 novembre 2018 13:30:19 CET, Kurt Roeckx ha scritto:
> > On Sun, Oct 28, 2018 at 11:29:43PM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote:
> >
On Sun, Oct 28, 2018 at 11:29:43PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote:
> > On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> > > &
--- Begin Message ---
Hi, everybody,
there is a new release of M2Crypto, most complete Python bindings
for OpenSSL (from 1.0.1e to 1.1.1), supporting both Python 2 (2.6
and 2.7) and Python 3 (from 3.4 upwards).
This is mostly bugfix release, including:
- support for OpenSSL 1.1.1
- Fixes
On Mon, Nov 05, 2018 at 12:28:50AM +0100, Sebastian Andrzej Siewior wrote:
>
> 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
On Sat, Nov 03, 2018 at 11:12:37AM +0100, Julien Lecomte wrote:
> Package: openssl
> Version: 1.1.1-2
> Severity: serious
> Justification: makes unrelated software on the system (or the whole system)
> break
>
> Dear Maintainer,
>
> On a fresh install of Debian/Buster via the alpha3 dvd ISO,
On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> > > Source: kopete
> > > Source-Version: 4:18.04.1-1
> > >
> &
On Sun, Oct 07, 2018 at 11:00:48AM +0200, Andrej Shadura wrote:
>
> I’m unsure what can be done to help resolve this issue from the wpa side.
The only thing I can think of is that wpa could add a way to
specify the minimum tls version.
I will enable SSLv2, SSLv3, 3DES, RC4, export ciphers, and so on again.
On Thu, Oct 18, 2018 at 04:05:32PM +0200, Mattia Rizzolo wrote:
> On Thu, Oct 18, 2018 at 04:01:59PM +0300, Niko Tyni wrote:
> > On Wed, Oct 17, 2018 at 09:21:29PM +0200, Kurt Roeckx wrote:
> > > On Wed, Oct 17, 2018 at 09:22:35PM +0300, Niko Tyni wrote:
> >
> > &
On Wed, Oct 17, 2018 at 09:22:35PM +0300, Niko Tyni wrote:
>
> As a status update, I count just six packages left in testing that are
> marked as blockers for this bug. (I could be wrong of course; double
> checking welcome.)
I think you missed one.
> - src:foolscap #898800: foolscap: FTBFS
All the errors in the test suite are problems in the test suite
itself. Some of those have been fixed upstream.
Some of the problems are:
- The test suite used 1024 bit keys, they have been replaced by
2048 bit keys
- The test suite didn't send the Finished message to the server,
the client
On Tue, Sep 11, 2018 at 08:14:35PM +0300, Dmitry Shachnev wrote:
> Hi Kurt,
>
> On Tue, Sep 11, 2018 at 07:09:04PM +0200, Kurt Roeckx wrote:
> > If this is for a call to SSL_CTX_set_max_proto_version(), you can
> > use 0 instead of TLS_MAX_VERSION.
>
> Good
On Tue, Sep 11, 2018 at 02:28:02PM +0200, Jonas Smedegaard wrote:
> Jan-Marek Glogowski wrote:
> > Qt5 is just the first breaking package - I have no idea, how many
> > packages use TLS_MAX_VERSION in their code.
>
> According to https://codesearch.debian.net/search?q=TLS_MAX_VERSION the
>
On Tue, Sep 11, 2018 at 04:11:02PM +0300, Adrian Bunk wrote:
>
> Dmitry already implemented my short-term workaround:
> https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/
If this is for a call to SSL_CTX_set_max_proto_version(), you can
use 0
Now that bug #907278 is fixed, I think this is fixed too.
Now that bug #907278 is fixed, I think this is fixed too.
On Wed, Sep 05, 2018 at 10:58:27PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-08-23 09:07:31 [+0200], Paul Gevers wrote:
> > 2) enable the openssl package to collect information which packages it
> > breaks and which version of those package fix the issue. With that
> > information the
This is most likely caused by google sending invalid certificates
if you talk TLS 1.3 but don't send the SNI extention. See
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication
On Tue, Aug 28, 2018 at 03:33:11PM +0200, Pierre-Elliott Bécue wrote:
> Le samedi 25 août 2018 à 20:34:35+0200, Kurt Roeckx a écrit :
> > This is caused by a Debian change to require a 2048 bit key by
> > default instead of a 1024 bit key. Since this is just for a test,
> >
This is caused by a Debian change to require a 2048 bit key by
default instead of a 1024 bit key. Since this is just for a test,
you can either just replace the certificates with larger keys,
or lower the security level for the test from 2 to 1. I suggest
you just create a new certificates.
Kurt
The most likely reason for a timeout is this:
*) SSL_MODE_AUTO_RETRY is enabled by default. Applications that use blocking
I/O in combination with something like select() or poll() will hang. This
can be turned off again using SSL_CTX_clear_mode().
Many applications do not
For more information about this, see:
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication
This is google enforcing SNI when you use TLS 1.3, see
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication
Kurt
The log shows:
> ERROR: SSL or crypto error: loading certificates from
> testfiles/clientCerts.pem: error:140AB18F:SSL
> routines:SSL_CTX_use_certificate:ee key too small
This is caused by a Debian change to require a 2048 bit key by
default instead of a 1024 bit key. Since this is just for a
Hi,
The problem is:
> Generating a 1024 bit RSA private key
Which then later results in:
> lua: server.lua:19: error loading certificate (ee key too small)
We've changed the default in Debian to require 2048 bit keys.
Kurt
severity 907049 important
thanks
On Sat, Aug 25, 2018 at 03:06:47PM +0200, Kurt Roeckx wrote:
> Anyway, that seems to mean that openvpn only supports TLS 1.0 for
> some reason. I have no idea how openvpn works, but if it uses
> TLS 1.0, it really should switch to 1.2 or 1.3.
S
reassign 907049 openvpn
severity 907049 serious
retitle 907049 openvpn: ssl_choose_client_version:version too low
block 907015 by 907049
thanks
On Sat, Aug 25, 2018 at 02:49:12PM +0200, Samuel Hym wrote:
> > Can you try with:
> > MinProtocol = TLSv1
> >
> > And with:
> > #MinProtocol = TLSv1.2
>
On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> Source: kopete
> Source-Version: 4:18.04.1-1
>
> We believe that the bug you reported is fixed in the latest version of
> kopete, which is due to be installed in the Debian FTP archive.
Any plans to upload this to unstable?
Kurt
On Mon, May 28, 2018 at 05:59:08PM +0200, Emilio Pozuelo Monfort wrote:
> On Tue, 17 Apr 2018 20:55:00 +0200 Emilio Pozuelo Monfort
> wrote:
> > On Wed, 24 Jan 2018 11:07:19 + deb...@fau.xxx wrote:
> > > Upstream have accepted both patches. netty 4.1.20 has been released,
> > > which will
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.
> >
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 m
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.
clone 907049 -1
reassign -1 offlineimap
severity -1 serious
retitle -1 offlineimap: Not using SNI
thanks
On Thu, Aug 23, 2018 at 02:54:36PM +0200, Antonin Kral wrote:
> Package: openssl
> Version: 1.1.1~~pre9-1
> Severity: critical
> Justification: renders other packages unusable
>
> Hi,
>
> I
On Fri, Aug 03, 2018 at 08:50:37PM +0200, Paul Gevers wrote:
> Dear madplay maintainers,
>
> It is my intent to upload madplay to the achieve in about 10 days
> containing the changes in the attached debdiff.
Just upload it
Kurt
Hi,
Any update on this?
There are very few packages in testing that still use OpenSSL
1.0.2, and it looks like openssh is the only reason to keep it
around.
Kurt
On Sun, Jul 08, 2018 at 03:05:34AM +0200, Michael Biebl wrote:
> Control: tags -1 moreinfo unreproducible
>
> Am 08.07.2018 um 00:26 schrieb Kurt Roeckx:
> > Package: udev
> > Version: 239-5
> > Severity: serious
> >
> > Hi,
> >
> > When upgrad
Package: udev
Version: 239-5
Severity: serious
Hi,
When upgrading udev, it failed to upgrade, because udev didn't
want to start. I think there might be some ordering problem.
This is the apt history log:
Start-Date: 2018-07-07 23:51:34
Commandline: apt-get upgrade
Upgrade: libsystemd0:amd64
On Tue, Jun 12, 2018 at 09:57:56PM +0200, Axel Beckert wrote:
> Hi,
>
> Thijs Kinkhorst wrote:
> > >> I've read about this bug (and the other one) on d-devel. I uploaded
> > >> recently a new version of openssl to unstable (1.1.0h-3)which changes
> > >> the exit code of "openssl rehash" to zero
On Wed, May 02, 2018 at 07:26:02PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-05-02 18:34:35 [+0200], Kurt Roeckx wrote:
> > On Wed, May 02, 2018 at 05:19:20PM +0100, Simon McVittie wrote:
> > > * https://github.com/openssl/openssl/pull/5967
> > >
> &g
On Wed, May 02, 2018 at 05:19:20PM +0100, Simon McVittie wrote:
> * https://github.com/openssl/openssl/pull/5967
>
> """
> Commit d316cdc introduced some extra
> checks into the session-cache update procedure, intended to prevent
> the caching of sessions whose resumption would lead to a
On Fri, Apr 06, 2018 at 07:54:44PM +0100, Simon McVittie wrote:
> On Fri, 06 Apr 2018 at 19:44:18 +0200, Kurt Roeckx wrote:
> > On Fri, Apr 06, 2018 at 01:58:03PM +0100, Simon McVittie wrote:
> > > This is probably a bug in libssl1.1 or in python-m2crypto, but I'm
> > &g
On Fri, Apr 06, 2018 at 01:58:03PM +0100, Simon McVittie wrote:
> Package: osc
> Version: 0.162.1-1
> Severity: grave
> Justification: osc tool becomes mostly unusable
>
> This is probably a bug in libssl1.1 or in python-m2crypto, but I'm
> reporting it against osc for now, because that's the
On Tue, Feb 27, 2018 at 09:39:11PM +0100, Sebastian Andrzej Siewior wrote:
> control: clone -1 -2
> control: reassign -2 libio-socket-ssl-perl 2.056-1
> control: severity -2 normal
> control: tags -2 patch
>
> On 2018-02-27 21:52:23 [+0800], 積丹尼 Dan Jacobson wrote:
> > Here is all you need to
On Tue, Feb 27, 2018 at 02:37:38AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: libssl1.1
> Version: 1.1.1~~pre1-1
> Severity: grave
>
> SSL connect attempt failed error:141A90B5:SSL
> routines:ssl_cipher_list_to_bytes:no ciphers available
See https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/
On Fri, Dec 29, 2017 at 02:57:11PM +0100, Andreas Henriksson wrote:
> Control: severity -1 serious
> Control: affects -1 iproute2
> Control: tags -1 + patch
>
> Hello,
>
> Missing dependency is a policy violation, thus bumping to severity
> to serious.
> Hopefully this can be fixed very soon (so
On Mon, Nov 13, 2017 at 12:09:05AM +0800, Daniel Kahn Gillmor wrote:
> On Sun 2017-11-12 15:45:26 +0100, Ondřej Surý wrote:
> > Control: forwarded -1
> > https://gitlab.labs.nic.cz/knot/knot-resolver/issues/272
> >
> > dkg, I told you :)
>
> I don't think this is the same problem. knot-resolver
1 - 100 of 2539 matches
Mail list logo
