Bug#995636: transition: openssl
On 2022-06-08 22:13:09 [+0200], Sebastian Ramacher wrote: > That would be much appreciated, thanks! Did so, sorry for the delay. I aimed for Monday but… > Cheers Sebastian
Bug#995636: transition: openssl
On 2022-06-05 19:50:33 +, Sebastian Andrzej Siewior wrote: > On 5 June 2022 19:03:17 UTC, Kurt Roeckx wrote: > >The suggestion was to make an openssl.cnf that's compatible with 1.1.1, > >and so remove or comment out everything related to providers. > > > > Ah okay. In that case let me so that tomorrow and close that rc bug with this > change. That would be much appreciated, thanks! Cheers > > > > >Kurt > > > > > -- > Sebastian > -- Sebastian Ramacher
Bug#995636: transition: openssl
Hi, Is there an ETA for this? Asking since openssl is blocking a number of rev-deps from migrating for almost a month by now. -- Best, Nilesh signature.asc Description: PGP signature
Bug#995636: transition: openssl
On 5 June 2022 19:03:17 UTC, Kurt Roeckx wrote: >The suggestion was to make an openssl.cnf that's compatible with 1.1.1, >and so remove or comment out everything related to providers. > Ah okay. In that case let me so that tomorrow and close that rc bug with this change. > >Kurt > -- Sebastian
Bug#995636: transition: openssl
On Sun, Jun 05, 2022 at 08:44:22PM +0200, Sebastian Andrzej Siewior wrote: > On 2022-06-05 19:42:43 [+0200], Sebastian Ramacher wrote: > > Hi Sebastian > Hi Sebastian, > > > > Otherwise I'd fear that the only other options are openssl breaking > > > libssl1.1 or renaming /etc/ssl/openssl.cnf to have a version specific > > > name. Given the high number reverse dependencies involved in this > > > transition (and also those depending on bin:openssl), I'd prefer to > > > avoid a Breaks that could have the potential to force the libssl1.1 -> > > > libssl3 upgrade to be more of a lockstep transition than needed. > > > > I see that there was another openssl upload. Any reason a fix for this > > issue wasn't included in the upload of 3.0.3-6? > > I wasn't aware that this is something that we want do. Kurt pointed me > to the testsuite problem which was the primary motivation for the > upload. > Regarding dovecot, Kurt wanted to make some time for it. The patch in > ubuntu is working but is a giant duct tape which is not something I > would wan to upload… > Anyway, regarding the openssl.cnf. Do we want to use openssl-3.cnf for > libssl3? We can't make opnenssl-1.1.cnf happen. The modification > openssl.cnf already happend so people need to make changes manually… > Is this the request here? The suggestion was to make an openssl.cnf that's compatible with 1.1.1, and so remove or comment out everything related to providers. Kurt
Bug#995636: transition: openssl
On 2022-06-05 19:42:43 [+0200], Sebastian Ramacher wrote: > Hi Sebastian Hi Sebastian, > > Otherwise I'd fear that the only other options are openssl breaking > > libssl1.1 or renaming /etc/ssl/openssl.cnf to have a version specific > > name. Given the high number reverse dependencies involved in this > > transition (and also those depending on bin:openssl), I'd prefer to > > avoid a Breaks that could have the potential to force the libssl1.1 -> > > libssl3 upgrade to be more of a lockstep transition than needed. > > I see that there was another openssl upload. Any reason a fix for this > issue wasn't included in the upload of 3.0.3-6? I wasn't aware that this is something that we want do. Kurt pointed me to the testsuite problem which was the primary motivation for the upload. Regarding dovecot, Kurt wanted to make some time for it. The patch in ubuntu is working but is a giant duct tape which is not something I would wan to upload… Anyway, regarding the openssl.cnf. Do we want to use openssl-3.cnf for libssl3? We can't make opnenssl-1.1.cnf happen. The modification openssl.cnf already happend so people need to make changes manually… Is this the request here? > Cheers Sebastian
Bug#995636: transition: openssl
Hi Sebastian On 2022-05-28 16:49:07, Sebastian Ramacher wrote: > On 2022-05-27 15:36:53 +0200, Kurt Roeckx wrote: > > On Thu, May 26, 2022 at 06:26:57PM +0200, Sebastian Ramacher wrote: > > > > > > That leaves #1011051. What's your view on that bug? > > > > So my understanding is that 1.1.1 doesn't understand the new > > configuration file and tries to load an engine (instead of a > > provider). > > > > We could ship a file that's comptabile with 1.1.1. That would make it > > a little bit harder to load some providers by default, but maybe that's > > something you want to do per application anyway. > > If that works, let's do that. > > Otherwise I'd fear that the only other options are openssl breaking > libssl1.1 or renaming /etc/ssl/openssl.cnf to have a version specific > name. Given the high number reverse dependencies involved in this > transition (and also those depending on bin:openssl), I'd prefer to > avoid a Breaks that could have the potential to force the libssl1.1 -> > libssl3 upgrade to be more of a lockstep transition than needed. I see that there was another openssl upload. Any reason a fix for this issue wasn't included in the upload of 3.0.3-6? Cheers -- Sebastian Ramacher
Bug#995636: transition: openssl
Hi On 2022-05-27 15:36:53 +0200, Kurt Roeckx wrote: > On Thu, May 26, 2022 at 06:26:57PM +0200, Sebastian Ramacher wrote: > > > > That leaves #1011051. What's your view on that bug? > > So my understanding is that 1.1.1 doesn't understand the new > configuration file and tries to load an engine (instead of a > provider). > > We could ship a file that's comptabile with 1.1.1. That would make it > a little bit harder to load some providers by default, but maybe that's > something you want to do per application anyway. If that works, let's do that. Otherwise I'd fear that the only other options are openssl breaking libssl1.1 or renaming /etc/ssl/openssl.cnf to have a version specific name. Given the high number reverse dependencies involved in this transition (and also those depending on bin:openssl), I'd prefer to avoid a Breaks that could have the potential to force the libssl1.1 -> libssl3 upgrade to be more of a lockstep transition than needed. Best Sebastian -- Sebastian Ramacher
Bug#995636: transition: openssl
On Thu, May 26, 2022 at 06:26:57PM +0200, Sebastian Ramacher wrote: > > That leaves #1011051. What's your view on that bug? So my understanding is that 1.1.1 doesn't understand the new configuration file and tries to load an engine (instead of a provider). We could ship a file that's comptabile with 1.1.1. That would make it a little bit harder to load some providers by default, but maybe that's something you want to do per application anyway. Kurt
Bug#995636: transition: openssl
On 2022-05-26 18:26:57 [+0200], Sebastian Ramacher wrote: > Hi Sebastian Hi, > We're now at the following blockers for openssl's migration: … > Bugs for the autopkgtest regressions have been filed and some are > already fixed in unstable. So I'll add hints to ignore those > regressions. good. > That leaves #1011051. What's your view on that bug? I intend to fix dovecot which should address it at some point. I don't know what we should expect if the syntax/anything changes between releases and it remains incompatible. We had a case we steam (I think?) and the they workarounded by overrideing the file. Kurt? > Cheers Sebastian
Bug#995636: transition: openssl
Hi Sebastian On 2022-05-13 23:49:33, Sebastian Andrzej Siewior wrote: > On 2022-05-09 00:11:22 [+0200], Sebastian Ramacher wrote: > > Control: tags -1 = confirmed > > > > Please go ahead > > Thank you, done. We're now at the following blockers for openssl's migration: ∙ Updating openssl would introduce bugs in testing: #1011051 ∙ autopkgtest for apache2/2.4.53-2: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻) ∙ autopkgtest for burp/2.4.0-3: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Not a regression ∙ autopkgtest for dovecot/1:2.3.18+dfsg1-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻) ∙ autopkgtest for easy-rsa/3.0.8-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻) ∙ autopkgtest for golang-github-mendersoftware-openssl/1.1.0-2: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻) ∙ autopkgtest for interimap/0.5.7-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻) ∙ autopkgtest for m2crypto/0.38.0-2: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻) ∙ autopkgtest for mender-client/3.0.0+ds1-2: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻) ∙ autopkgtest for puma/5.5.2-2: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Ignored failure, s390x: Pass ∙ autopkgtest for serf/1.3.9-10: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻) Bugs for the autopkgtest regressions have been filed and some are already fixed in unstable. So I'll add hints to ignore those regressions. That leaves #1011051. What's your view on that bug? Cheers -- Sebastian Ramacher
Bug#995636: transition: openssl
On 2022-05-15 20:33:09 +0300, Adrian Bunk wrote: > Static libraries are not linked with libraries they use, > and usage of static-only libraries that use OpenSSL gets > broken in a way not handled either way by the tracker. > > Trying to link a library that was built with OpenSSL 1.1 > together with OpenSSL 3.0 into a program is not supposed > to work. > > Two issues seen so far: > > 1. #1006512 was a false positive, ocaml-cohttp can be binNMU'ed now > that ocaml-ssl has been binNMU'ed. > > 2. libtgowt needs a binNMU, this is needed for telegram-desktop. Both scheduled Cheers -- Sebastian Ramacher
Bug#995636: transition: openssl
Static libraries are not linked with libraries they use, and usage of static-only libraries that use OpenSSL gets broken in a way not handled either way by the tracker. Trying to link a library that was built with OpenSSL 1.1 together with OpenSSL 3.0 into a program is not supposed to work. Two issues seen so far: 1. #1006512 was a false positive, ocaml-cohttp can be binNMU'ed now that ocaml-ssl has been binNMU'ed. 2. libtgowt needs a binNMU, this is needed for telegram-desktop. cu Adrian
Bug#995636: transition: openssl
On 2022-05-09 00:11:22 [+0200], Sebastian Ramacher wrote: > Control: tags -1 = confirmed > > Please go ahead Thank you, done. > Cheers Sebastian
Bug#995636: transition: openssl
Control: tags -1 = confirmed On 2022-03-01 23:39:13 +0100, Sebastian Andrzej Siewior wrote: > Control: tags -1 - moreinfo > > Removing moreinfo tag since I provide more information in my previous > reply. > > On 2022-02-28 00:23:22 [+0100], To 995...@bugs.debian.org wrote: > > On 2022-02-14 15:01:34 [+0100], To Sebastian Ramacher wrote: > > > On 2022-02-01 21:11:11 [+0100], Sebastian Ramacher wrote: > > > > > Could you please update this transition request? It's open for four > > > > > months and no visible response. > > > > > > > > Kurt mention some 100 packages failing to build. I only see a handfull > > > > of bugs filed. So what's the status on those build failures? > > > > > > So new logs probably… > > > > Gathered new logs and finally processed them \o/. The list at > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0 > > > > has been updated accordingly. I added bugs for packages for FTBFS which > > existed without new openssl (say due new gcc, old debhelper, …). I was > > not able to build a few packages (25) because the build dependency could > > not have been satisfied at the time. Please go ahead Cheers -- Sebastian Ramacher
Bug#995636: transition: openssl
Control: tags -1 - moreinfo Removing moreinfo tag since I provide more information in my previous reply. On 2022-02-28 00:23:22 [+0100], To 995...@bugs.debian.org wrote: > On 2022-02-14 15:01:34 [+0100], To Sebastian Ramacher wrote: > > On 2022-02-01 21:11:11 [+0100], Sebastian Ramacher wrote: > > > > Could you please update this transition request? It's open for four > > > > months and no visible response. > > > > > > Kurt mention some 100 packages failing to build. I only see a handfull > > > of bugs filed. So what's the status on those build failures? > > > > So new logs probably… > > Gathered new logs and finally processed them \o/. The list at > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0 > > has been updated accordingly. I added bugs for packages for FTBFS which > existed without new openssl (say due new gcc, old debhelper, …). I was > not able to build a few packages (25) because the build dependency could > not have been satisfied at the time. Sebastian
Bug#995636: transition: openssl
On 2022-02-14 15:01:34 [+0100], To Sebastian Ramacher wrote: > On 2022-02-01 21:11:11 [+0100], Sebastian Ramacher wrote: > > > Could you please update this transition request? It's open for four > > > months and no visible response. > > > > Kurt mention some 100 packages failing to build. I only see a handfull > > of bugs filed. So what's the status on those build failures? > > So new logs probably… Gathered new logs and finally processed them \o/. The list at https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0 has been updated accordingly. I added bugs for packages for FTBFS which existed without new openssl (say due new gcc, old debhelper, …). I was not able to build a few packages (25) because the build dependency could not have been satisfied at the time. Sebastian
Bug#995636: transition: openssl
On 2022-02-01 21:11:11 [+0100], Sebastian Ramacher wrote: > > Could you please update this transition request? It's open for four > > months and no visible response. > > Kurt mention some 100 packages failing to build. I only see a handfull > of bugs filed. So what's the status on those build failures? I'm not sure. I checked & filled some bugs over the weekend and added a few which were filled by ubuntu dev but not tagged as Kurt did. This took more time than expected. I will probably do a rebuild of the packages to be sure to have the view of today. Some build failures got fixed in the meantime while the packages are listed as "fail" in my old (OCT) logs (php, ruby3 (not ruby2 but is going to be removed)). So new logs probably… > Cheers Sebastian
Bug#995636: transition: openssl
Control: tags -1 moreinfo On 2022-02-01 15:36:37 +0100, Bastian Blank wrote: > Hi release team > > On Sun, Oct 03, 2021 at 02:59:31PM +0200, Kurt Roeckx wrote: > > We would like to transition to OpenSSL 3.0.0. It's currently in > > experimental. It has an soname change, so the binary packages got > > renamed and binNMUs will be required. > > Could you please update this transition request? It's open for four > months and no visible response. Kurt mention some 100 packages failing to build. I only see a handfull of bugs filed. So what's the status on those build failures? Cheers > > Bastian > > -- > Each kiss is as the first. > -- Miramanee, Kirk's wife, "The Paradise Syndrome", > stardate 4842.6 > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#995636: transition: openssl
Hi release team On Sun, Oct 03, 2021 at 02:59:31PM +0200, Kurt Roeckx wrote: > We would like to transition to OpenSSL 3.0.0. It's currently in > experimental. It has an soname change, so the binary packages got > renamed and binNMUs will be required. Could you please update this transition request? It's open for four months and no visible response. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)
Paul Wise writes: > On Wed, Oct 6, 2021 at 11:30 AM Luca Boccassi wrote: >> On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote: >> > Additionally OpenSSL is considered system library, see >> > https://bugs.debian.org/951780 >> > https://bugs.debian.org/972181 >> >> Even if that interpretation holds, and it's not a universal >> interpretation (eg: lawyers from Canonical strongly disagree as far as >> I know), again that applies to first-party binaries only as far as I >> understand. It's not as clear-cut with libraries used by third parties. I believe Canonical also ships GPL-2-only programs linked (possibly indirectly) to OpenSSL as part of their Linux distribution these days. > As I understand it, it is meant only for binaries distributed by > parties other than the one distributing the system containing the > "system library". So third-party app distributors are fine to ignore > the incompatibility between a GPL app and a proprietary libc, but the > OS vendor can't include GPL apps linked to that proprietary libc > within their system. Debian uses many GPL-2-incompatible system libraries: for example GPL-3-or-later libraries such as libstdc++ or libgcc or gnutls[1]. Debian also ships many GPL-2-only programs using these. So if this was considered a problem, then the problem would be quite large. [1]: gnutls could be made LGPL-2.1-or-later by rewriting the GPL-3-or-later build scripts; note that GPL-2 states that "complete source code" includes "scripts used to control compilation and installation of the executable" > I believe OpenSSL 3's choice of the Apache 2 license only improves > compatibility, it doesn't reduce it. GPLv3 is supposedly compatible > with Apache 2, so GPLv3 and GPLv2+ programs are newly compatible with > OpenSSL 3. Most existing GPLv2-only programs that use OpenSSL will > have the exception anyway. This depends on what you mean by "use OpenSSL": if program use OpenSSL directly, maybe; if programs link to OpenSSL indirectly, for example via dependency chains such as my-program -> some-library -> some-library-implementing-some-network-protocol -> OpenSSL this becomes increasingly unlikely the longer the chain is. Also people seem to keep adding TLS support to more and more libraries, so such a dependency can just silently appear later. Python programs using OpenSSL also usually don't have such an exception. , Ansgar
Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)
On Wed, Oct 6, 2021 at 11:30 AM Luca Boccassi wrote: > On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote: > > Additionally OpenSSL is considered system library, see > > https://bugs.debian.org/951780 > > https://bugs.debian.org/972181 > > Even if that interpretation holds, and it's not a universal > interpretation (eg: lawyers from Canonical strongly disagree as far as > I know), again that applies to first-party binaries only as far as I > understand. It's not as clear-cut with libraries used by third parties. As I understand it, it is meant only for binaries distributed by parties other than the one distributing the system containing the "system library". So third-party app distributors are fine to ignore the incompatibility between a GPL app and a proprietary libc, but the OS vendor can't include GPL apps linked to that proprietary libc within their system. https://lists.debian.org/debian-devel/2020/10/msg00168.html > The core issue as always is uncertainty: any time there are doubts and > conflicting interpretations, we all lose, especially our users, and > especially those that are then forced to have awkward conversations > with their corporate lawyers. Which is why it's really unfortunate that > , in order to fix compatibility issues with the GPL, among all the > permissive licenses available out there, the OpenSSL project picked the > _one_ that has serious compatibility questions with the GPL :-( I believe OpenSSL 3's choice of the Apache 2 license only improves compatibility, it doesn't reduce it. GPLv3 is supposedly compatible with Apache 2, so GPLv3 and GPLv2+ programs are newly compatible with OpenSSL 3. Most existing GPLv2-only programs that use OpenSSL will have the exception anyway. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)
On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote: > On 2021-10-05 20:03:49 [+0200], Michael Biebl wrote: > > Hi Kurt, hi Luca, hi everyone, > Hi Michael, > > > That said, I'm not a lawyer and reading license texts hurts my brain. > > So my goal is is mainly to raise awareness of this issue and seek input from > > the community. > > GPL code which linked against OpenSSL usually has a "gpl-exception > clause for OpenSSL". This should be still accepted since it refers > specifically to OpenSSL. Many projects do not have that. Also to be extremely pedantic it needs to be checked if it just references OpenSSL as a project, or specifically the OpenSSL license which is a specific and well defined document: https://spdx.org/licenses/OpenSSL.html AFAIK there's no "standard" clause, everyone uses their own wording, more or less. More importantly, as far as I understand and I was told recently these are not transitive - ie, it's fine for an executable, but if it concerns a library, it does not "transfer" to external programs linking to that library. > Additionally OpenSSL is considered system library, see > https://bugs.debian.org/951780 > https://bugs.debian.org/972181 Even if that interpretation holds, and it's not a universal interpretation (eg: lawyers from Canonical strongly disagree as far as I know), again that applies to first-party binaries only as far as I understand. It's not as clear-cut with libraries used by third parties. The core issue as always is uncertainty: any time there are doubts and conflicting interpretations, we all lose, especially our users, and especially those that are then forced to have awkward conversations with their corporate lawyers. Which is why it's really unfortunate that , in order to fix compatibility issues with the GPL, among all the permissive licenses available out there, the OpenSSL project picked the _one_ that has serious compatibility questions with the GPL :-( But of course this doesn't mean we shouldn't move to the new version, quite the contrary - I'll simply be careful about the projects I am involved in and what it means for them and their license clarity, and what I can do to make it better, if anything. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)
On 2021-10-05 20:03:49 [+0200], Michael Biebl wrote: > Hi Kurt, hi Luca, hi everyone, Hi Michael, > That said, I'm not a lawyer and reading license texts hurts my brain. > So my goal is is mainly to raise awareness of this issue and seek input from > the community. GPL code which linked against OpenSSL usually has a "gpl-exception clause for OpenSSL". This should be still accepted since it refers specifically to OpenSSL. Additionally OpenSSL is considered system library, see https://bugs.debian.org/951780 https://bugs.debian.org/972181 > Regards, > Michael Sebastian
Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)
Hi Kurt, hi Luca, hi everyone, regarding the impending transition to OpenSSL 3.0 in unstable (which is now licensed under Apache 2.0), I wonder what that means for Debian, given that apparently GPL-2 (and also LGPL-2) and Apache 2.0 are incompatible with each other. If I read Luca correctly[1], any library or executable using GPL-2+ effectively becomes GPL-3+ once they link against OpenSSL 3.0. And especially for libraries, this would have a ripple effect through the whole distribution and cause issues e.g for GPL-2 only packages. Fwiw, I'm surprised that this also apparently affects LGPL-2. That said, I'm not a lawyer and reading license texts hurts my brain. So my goal is is mainly to raise awareness of this issue and seek input from the community. Regards, Michael Am 03.10.21 um 14:59 schrieb Kurt Roeckx: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We would like to transition to OpenSSL 3.0.0. It's currently in experimental. It has an soname change, so the binary packages got renamed and binNMUs will be required. We did a rebuild of packages and currently have 105 packages that FTBFS with OpenSSL 3.0.0 that build with 1.1.1. I've started filing bugs for that: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0 Kurt [1] https://github.com/systemd/systemd/pull/20915 OpenPGP_signature Description: OpenPGP digital signature
Bug#995636: transition: openssl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We would like to transition to OpenSSL 3.0.0. It's currently in experimental. It has an soname change, so the binary packages got renamed and binNMUs will be required. We did a rebuild of packages and currently have 105 packages that FTBFS with OpenSSL 3.0.0 that build with 1.1.1. I've started filing bugs for that: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0 Kurt
