Re: [openssl-project] Random devices in chroot environments revisited

On Tue, Oct 30, 2018 at 07:23:52PM +, Dr. Matthias St. Pierre wrote: > Hi, > > I'd like to recall that the following issue > > #7419 - RAND_keep_random_devices_open not working > > still needs to be fixed until 1.1.1a and that currently there are two > alternative approaches for doing

Re: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

On Tue, Oct 30, 2018 at 10:15:44AM -0400, Theodore Y. Ts'o wrote: > On Tue, Oct 30, 2018 at 01:18:08AM +0100, Sebastian Andrzej Siewior wrote: > > Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to > > /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment > > the

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

On Tue, Oct 30, 2018 at 10:15:44AM -0400, Theodore Y. Ts'o wrote: > On Tue, Oct 30, 2018 at 01:18:08AM +0100, Sebastian Andrzej Siewior wrote: > > Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to > > /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment > > the

Re: Questions regarding the qualifications and competency of TUVIT

On 2018-10-30 16:20, Ryan Sleevi wrote: Given that the Supervisory Body and National Accreditation bodies exist to protect the legal value of this scheme, the failure by TUVIT to uphold the safety and security of the eIDAS regime represents an ongoing threat to the ecosystem. Do we have a way

Bug#912087: [Pkg-openssl-devel] Bug#912087: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

On Mon, Oct 29, 2018 at 09:58:20PM +0100, Sebastian Andrzej Siewior wrote: > On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote: > > So I believe this is not an openssl issue, but something in the > > order that the kernel's RNG is initialized and openssh is started. > > Potent

Bug#912087: [Pkg-openssl-devel] Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

On Mon, Oct 29, 2018 at 07:11:17PM +0100, Michael Biebl wrote: > On Mon, 29 Oct 2018 18:22:08 +0100 Kurt Roeckx wrote: > > reassign 912087 openssh-server,systemd > > thanks > > > > On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote: > > > On Mon, Oct

Bug#912087: [Pkg-openssl-devel] Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

On Mon, Oct 29, 2018 at 07:11:17PM +0100, Michael Biebl wrote: > On Mon, 29 Oct 2018 18:22:08 +0100 Kurt Roeckx wrote: > > reassign 912087 openssh-server,systemd > > thanks > > > > On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote: > > > On Mon, Oct

Bug#912087: [Pkg-openssl-devel] Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

reassign 912087 openssh-server,systemd thanks On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote: > On Mon, Oct 29, 2018 at 12:28:15AM +, Colin Watson wrote: > > Reassigning to OpenSSL - could the OpenSSL maintainers please have a > > look and advise what's be

Bug#912087: [Pkg-openssl-devel] Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

On Mon, Oct 29, 2018 at 12:28:15AM +, Colin Watson wrote: > Reassigning to OpenSSL - could the OpenSSL maintainers please have a > look and advise what's best to do? (See the start of the bug, reporting > a delay of more than one minute in system boot in some cases, mainly > waiting for sshd

Bug#912067: [Pkg-openssl-devel] Bug#912067: libssl1.1: please add getmail/getmail4 to the dependencies to check

On Sat, Oct 27, 2018 at 05:18:22PM -0400, ant wrote: > > = > getmail version 5.6 > Copyright (C) 1998-2012 Charles Cazabon. Licensed under the GNU GPL version > 2. > SimplePOP3SSLRetriever:a...@anthive.com@mail.anthive.com:995: > rc-03ant: socket error ([SSL: UNSUPPORTED_PROTOCOL]

Bug#912067: [Pkg-openssl-devel] Bug#912067: libssl1.1: please add getmail/getmail4 to the dependencies to check

On Sat, Oct 27, 2018 at 04:30:13PM -0400, ant wrote: > Package: libssl1.1 > Version: 1.1.0h-4 > Severity: wishlist > > Dear Maintainer, > > hi, > > last year an upgrade of libssl1.1 ended up breaking > getmail/getmail4. the maintainer suggested a blocking > bug or something

Bug#858938: fixed in kopete 4:18.04.1-1

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 > > > > &

Bug#858938: fixed in kopete 4:18.04.1-1

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 > > > > &

Bug#858938: fixed in kopete 4:18.04.1-1

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 > > > > &

Bug#907518: wpa: problems with openssl 1.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.

Bug#907518: wpa: problems with openssl 1.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.

Bug#911389: [Pkg-openssl-devel] Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0

I will enable SSLv2, SSLv3, 3DES, RC4, export ciphers, and so on again.

Bug#911389: [Pkg-openssl-devel] Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0

I will enable SSLv2, SSLv3, 3DES, RC4, export ciphers, and so on again.

Re: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

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: > > > > &

Bug#907015: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

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: > > > > &

Bug#907015: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

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: > > > > &

Bug#907015: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

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

Bug#907015: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

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

Re: Audit Reminder Email Summary

On Tue, Oct 16, 2018 at 12:49:41PM -0700, Kathleen Wilson via dev-security-policy wrote: > Forwarded Message > Subject: Summary of October 2018 Audit Reminder Emails > Date: Tue, 16 Oct 2018 19:00:37 + (GMT) > > Mozilla: Audit Reminder > Root Certificates: >AC Raíz

Re: [openssl-project] Current priorities

On Tue, Sep 18, 2018 at 08:06:12PM +0200, Kurt Roeckx wrote: > The open PRs were around 100 when 1.1.0 was released, and have > been around 120 for a very long time, but the last few months it has > grown to around 150. I guess we have some that are waiting because > they are

Bug#907219: m2crypto: testsuite problems with OpenSSL 1.1.1

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

Bug#907219: m2crypto: testsuite problems with OpenSSL 1.1.1

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

[openssl-commits] [web] master update

The branch master has been updated via 3b07e5291b0df2cef8469ab0494d1c787e84af87 (commit) from 72c1892c6630fe39a3ba99980876a4e7e983a2d8 (commit) - Log - commit 3b07e5291b0df2cef8469ab0494d1c787e84af87 Author: Kurt

Re: [openssl-project] dropping out

On Fri, Oct 12, 2018 at 02:01:42PM +0200, Andy Polyakov wrote: > Another contributing factor is lack of opportunities to pursue > so to say "fundamental" goals, formal validation of assembly code being > one example. Formal validation of the assembly code is something I would actually like to

Re: [openssl-project] Minimum C version

On Sun, Oct 07, 2018 at 02:01:36PM +0100, David Woodhouse wrote: > Unfortunately Microsoft still does not support C99, I believe. Or did that > get fixed eventually, in a version that can reasonably be required? That is a very good point, and they never intend to fix that. So would that mean we

[openssl-project] Minimum C version

Hi, We're currently still targetting C89/C90 + long long, yet use various features of C99 and even some C11 when it's available. C99 is now almost 20 years old, can we please move to at least that? Kurt ___ openssl-project mailing list

Bug#910459: [Pkg-openssl-devel] Bug#910459: Bug#910459: openssl: broken autopkgtest

On Sat, Oct 06, 2018 at 06:19:32PM +0200, Kurt Roeckx wrote: > On Sat, Oct 06, 2018 at 12:36:44PM -0300, Antonio Terceiro wrote: > > Source: openssl > > Version: 1.1.1-1 > > Severity: normal > > Tags: patch > > > > The autopkgtests for openssl are

Bug#910459: [Pkg-openssl-devel] Bug#910459: openssl: broken autopkgtest

On Sat, Oct 06, 2018 at 12:36:44PM -0300, Antonio Terceiro wrote: > Source: openssl > Version: 1.1.1-1 > Severity: normal > Tags: patch > > The autopkgtests for openssl are currently broken due to a set of typos: This should already be fixed in git. Kurt

[issue32947] Support OpenSSL 1.1.1

Kurt Roeckx added the comment: Do you have any idea when the next release will be? I think python is currently our biggest blocker for getting OpenSSL 1.1.1 in Debian testing. -- ___ Python tracker <https://bugs.python.org/issue32

Re: [openssl-project] Release strategy updates & other policies

On Tue, Sep 25, 2018 at 08:13:53PM +1000, Tim Hudson wrote: > On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell wrote: > > > On 25/09/18 10:58, Tim Hudson wrote: > > > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte > > > wrote: > > > > > > So what you suggest (and

[issue32947] Support OpenSSL 1.1.1

Kurt Roeckx added the comment: Christian, Do you have any update on this? Any idea when we can expect relased python versions that work with OpenSSL 1.1.1? -- ___ Python tracker <https://bugs.python.org/issue32

Bug#574335: [pkg-ntp-maintainers] Bug#574335: ntpd shouldn't be started automatically

On Tue, Sep 18, 2018 at 11:44:29PM +0200, Bernhard Schmidt wrote: > > I have no idea how we can properly avoid that. When do you think > > would be a good time to reset the clock? After a reboot? I think > > it's not very obvious that you'd have to start it manually or > > reboot it after

Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

On Tue, Sep 18, 2018 at 05:11:42PM +, Salz, Rich via openssl-users wrote: > >My point was about the likelihood of last-draft browsers lingering > on in the real world for some time (like 1 to 3 years) after the > TLS1.3-final browser versions ship. > > I do not think this is a

[openssl-project] Current priorities

Hi, Now that 1.1.1 is released, and before everybody starts to work on new features, I would like to suggest that we work on reducing the number of open pull requests and issues. Fixing issues that are regressions in the 1.1.1 version is something we really should be doing, and I think that

[openssl-commits] [openssl] OpenSSL_1_1_1-stable update

Author: Kurt Roeckx Date: Tue Sep 11 23:39:25 2018 +0200 Improve SSL_shutdown() documentation Reviewed-by: Ben Kaduk GH: #7188 (cherry picked from commit 8e593f0a0dbcb3193548ced3c2e78fbbd201b2db) --- Summary

[openssl-commits] [openssl] master update

The branch master has been updated via 8e593f0a0dbcb3193548ced3c2e78fbbd201b2db (commit) from cd92d1fdd39819595e4b200bb82d8a0e9c76cfa5 (commit) - Log - commit 8e593f0a0dbcb3193548ced3c2e78fbbd201b2db Author: Kurt

Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote: > On 13/09/2018 09:57, Klaus Keppler wrote: > > Hi, > > > > thank you for all your responses. > > > > I've just tested with Firefox Nightly 64.0a1, and both s_server and our > > own app (using OpenSSL 1.1.1-release) are working fine. >

Bug#908751: [Pkg-openssl-devel] Bug#908751: openssl: testing SMTP connection with s?client output is impossible

On Thu, Sep 13, 2018 at 12:50:12PM +0100, mi wrote: > Package: openssl > Version: 1.1.1-1 > Severity: normal > > when running the command > > openssl s_client -connect mailserver:25 -starttls smtp -crlf -quiet > > everything works fine > if I leave out the parameter -quiet, the "RCPT TO:

Re: [Pkg-openssl-devel] OpenSSL+Qt interoperability?

On Tue, Sep 11, 2018 at 10:43:26PM +0300, Antti Järvinen wrote: > Dear OpenSSL+Qt Sirs, Please try 5.11.1+dfsg-8. Kurt

Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server

On Tue, Sep 11, 2018 at 08:10:01PM +0200, Kurt Roeckx wrote: > On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > > Hello, > > > > What is the better way, for anyone running, by example, Apache or nginx on > > a popular Linux districution (Ubuntu, Debian,

Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server

On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > Hello, > > What is the better way, for anyone running, by example, Apache or nginx on > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > 1.3 ? > > Waiting package update to have openssl 1.1.1 ? probably a lot

Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

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

Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

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

Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

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

Bug#908567: [Pkg-openssl-devel] Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

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 >

Bug#908567: [Pkg-openssl-devel] Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

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 >

Bug#907774: [Pkg-openssl-devel] Bug#908567: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

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

Bug#907774: [Pkg-openssl-devel] Bug#908567: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

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

Bug#907774: [Pkg-openssl-devel] Bug#908567: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

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

Bug#907491: goobook fails to authenticate

Now that bug #907278 is fixed, I think this is fixed too.

Bug#907491: goobook fails to authenticate

Now that bug #907278 is fixed, I think this is fixed too.

Re: [openssl-users] Version negotiation failure failure?

On Fri, Aug 31, 2018 at 06:14:25PM -0700, Jordan Brown wrote: > We're trying to nail down error reporting for TLS version mismatches, > and we're seeing a couple of puzzling behaviors. > > First, and most puzzling... assume these two command lines: > > $ openssl s_server -cert

Re: [openssl-project] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

On Sun, Sep 09, 2018 at 11:44:33PM +0100, Matt Caswell wrote: > > As far as the release criteria go we only count the ones shown in the > Coverity tool. That's not to say we shouldn't fix issues in the tests as > well (and actually I'd suggest we stop filtering out problems in the > tests if

Bug#908286: Buster: Drop ifupdown-hooks from ntpdate?

On Sat, Sep 08, 2018 at 01:23:41AM +0200, Bernhard Schmidt wrote: > Package: ntpdate > Severity: normal > > Hi Kurt (and everyone else in the BTS), > > I've been going through the open bugs in the BTS again and have come to the > conclusion that the whole ifupdown triggering mechanism included

Bug#907906: stretch-pu: package openssl/1.1.0f-3+deb9u2

On Tue, Sep 04, 2018 at 04:41:32PM +0200, Moritz Mühlenhoff wrote: > > (I've been deploying customs debs of the 1.0.2x and 1.1.0x openssl releases > at work and I haven't run into any compatibility issues/API issues during > that). We should really do upload all the latest point releases to all

Bug#907906: stretch-pu: package openssl/1.1.0f-3+deb9u2

On Tue, Sep 04, 2018 at 04:41:32PM +0200, Moritz Mühlenhoff wrote: > > (I've been deploying customs debs of the 1.0.2x and 1.1.0x openssl releases > at work and I haven't run into any compatibility issues/API issues during > that). We should really do upload all the latest point releases to all

Re: [openssl-project] Release Criteria Update

On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote: > Current status of the 1.1.1 PRs/issues: Since we did make a lot of changes, including things that applications can run into, would it make sense to have an other beta release? Kurt ___

Bug#907278: goobook fails to authenticate

Now that bug #907278 is fixed, I think this is fixed too.

Bug#907278: goobook fails to authenticate

Now that bug #907278 is fixed, I think this is fixed too.

Bug#907518: wpa: problems with openssl 1.1.1

The problem here is that the CA you're connecting to has an insecure certificate. You should talk to your administrator to generate stronger keys. The "ca md too weak" is because the certificate is probably using SHA-1, while it should move to SHA256. This can be worked around by using this in

Bug#907888: [Pkg-openssl-devel] Bug#907888: Bug#907888: openssl: Breaks wpa_supplicant (and NetworkManager) which fail with error "ee key too small"

On Tue, Sep 04, 2018 at 11:41:48AM +0200, Gianpaolo Cugola wrote: > > 1. Administrators of big organizations are usually reluctant to change > their certificates Can you at least try to contact them? > 2. The suggested workaround works (thanks again) for wpa_supplicant but > NetworkManager

Bug#907015: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

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

Bug#907015: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

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

Re: [openssl-project] Current status of our release criteria

On Mon, Sep 03, 2018 at 05:54:52PM +0100, Matt Caswell wrote: > > #7014: TLSv1.2 SNI hostname works in 1.1.0h, not in 1.1.1 master (as of 18 > > Ben has asked for input from the OMC on this one So SSL_get_servername() was not documented in 1.1.0, but did exist in it. It's currently documented

Re: [openssl-project] Current status of our release criteria

On Mon, Sep 03, 2018 at 05:54:52PM +0100, Matt Caswell wrote: > > #7058: Process handshake messages after we've send a shutdown > > Awaiting updates from @kroeckx...Kurt will you able to do that soon? Or > alternatively (if you prefer) I can take this one over. I was waiting for your feedback,

Bug#907888: [Pkg-openssl-devel] Bug#907888: opopenssl: Breaks wpa_supplicant (and NetworkManager) which fail with error "ee key too small"

On Mon, Sep 03, 2018 at 06:26:05PM +0200, Gianpaolo Cugola wrote: > TLS: Got certificate from PKCS12: > subject='/C=IT/ST=Lombardia/L=Milano/O=Politecnico di Milano/OU=Area > Sistemi ICT/CN=x...@xxx.xx' > TLS: Got private key from PKCS12 > TLS - SSL error: error:140C618F:SSL

Bug#907491: goobook fails to authenticate

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

Bug#907491: goobook fails to authenticate

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

Bug#907168: pytest-httpbin FTBFS with OpenSSL 1.1.1

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, > >

Bug#907168: pytest-httpbin FTBFS with OpenSSL 1.1.1

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, > >

Bug#907168: pytest-httpbin FTBFS with OpenSSL 1.1.1

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

Bug#907168: pytest-httpbin FTBFS with OpenSSL 1.1.1

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

[Python-modules-team] Bug#907168: pytest-httpbin FTBFS with OpenSSL 1.1.1

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

Bug#907022: puma: autopkgtest times out after update of openssl

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

Bug#907022: puma: autopkgtest times out after update of openssl

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

[DRE-maint] Bug#907022: puma: autopkgtest times out after update of openssl

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

Bug#907079: offlineimap: Not using SNI

For more information about this, see: https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication

Bug#907079: offlineimap: Not using SNI

For more information about this, see: https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication

Bug#906955: isync: can't verify some ssl certificate(e.g. imap.gmail.com)

This is google enforcing SNI when you use TLS 1.3, see https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication Kurt

Bug#906955: isync: can't verify some ssl certificate(e.g. imap.gmail.com)

This is google enforcing SNI when you use TLS 1.3, see https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication Kurt

Bug#907135: boxbackup: FTBFS with OpenSSL 1.1.1

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

Bug#907135: boxbackup: FTBFS with OpenSSL 1.1.1

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

Bug#907135: boxbackup: FTBFS with OpenSSL 1.1.1

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

Bug#906997: lua-sec: FTBFS with OpenSSL 1.1.1: test failure

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

Bug#906997: lua-sec: FTBFS with OpenSSL 1.1.1: test failure

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

Bug#907049: [Pkg-openssl-devel] Bug#907049: Bug#907049: openssl: Update to 1.1.1~~pre9-1 makes certain programs unusable

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

Bug#907049: [Pkg-openssl-devel] Bug#907049: Bug#907049: openssl: Update to 1.1.1~~pre9-1 makes certain programs unusable

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

Bug#907049: [Pkg-openssl-devel] Bug#907049: openssl: Update to 1.1.1~~pre9-1 makes certain programs unusable

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 >

Bug#907049: [Pkg-openssl-devel] Bug#907049: openssl: Update to 1.1.1~~pre9-1 makes certain programs unusable

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 >

Bug#858938: fixed in kopete 4:18.04.1-1

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

Bug#858938: fixed in kopete 4:18.04.1-1

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

Bug#858938: fixed in kopete 4:18.04.1-1

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

Bug#828451: netty fix released, netty-tcnative patch accepted

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

Bug#828451: netty fix released, netty-tcnative patch accepted

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

Bug#828451: netty fix released, netty-tcnative patch accepted

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

<    6   7   8   9   10   11   12   13   14   15   >