Re: OpenSSL 3.0 transition plans
On Tue, Oct 12, 2021 at 06:04:51PM +0100, Dimitri John Ledkov wrote: > > (my apologies, this mail will likely contain quite a few links) > > I looked a little bit into this, and as of 8 hours ago, the embedded copy > > of OpenSSL has been updated to version 3.0.0[0]. They have an open issue > > tracking the OpenSSL 3.0 support situation[1], and their technical > > committee has a document specifiying which OpenSSL release is supported > > for a given NodeJS version[2]. > > According to this comment[3] it seems they don't plan on supporting > > OpenSSL 3.0 in the 16.x branch, but rather in the 17.x which will have > > its first release next week according to their release schedule[4]. > > Sadly, the new 17.x branch isn't planned as an LTS one. > > Looking inwards, we currently ship a NodeJS version based on the 12.x > > branch, and Debian seems to be planning[5] a transition towards the 14.x > > branch. None of which support OpenSSL 3.0. > > Unless I'm missing something, I see the following options, in no > > particular order: > > (a) Remove NodeJS from the archive. Had to be mentioned, but I don't > > think it's realistic ;-) > > (b) Keep in sync with Debian, use the 14.x branch, but keep OpenSSL 1.1.1 > > in the archive via a compat package. > > (b') The same but using the embedded copy of OpenSSL (if even possible?). > (b') has been done in the past in Debian, and can be done again in > Debian/Ubuntu. > I'm not sure how well extensions compile when one does that and if we > will still need to package nodejs-openssl headers somewhere. Doing > (b') imho is less liability than packaging and providing 1.1.1 in the > archive, as despite all pleas people tend to assume that they don't > need to do anything and can stick with 1.1.1 for another ten years > without doing any work to migrate to 3.0.0. I wanted to argue that this was not an openssl-specific problem, but rather that if there were problems with understanding the support of main vs universe it should be addressed by more systematically socializing this. However, ESM makes this all a lot more fuzzy. An openssl 1.1.1 used by only one reverse-dependency (hypothetically) is not going to be high on the list of packages to get security updates on in ESM; but its presence in universe plus the existence of ESM could easily give users a different impression and lead them to rely on it. So if there are no other packages left in universe requiring openssl 1.1 at 22.04 release time (which is a big if), I am also in favor of b'). If there are other universe packages which still need 1.1.1 for 22.04, which seems likely, then b) is the right answer. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenSSL 3.0 transition plans
On Mon, Oct 11, 2021 at 06:47:45AM -0700, Simon Chopin wrote: > Hi Robie, > > Quoting Robie Basak (2021-10-11 12:39:00) > > I think it's worth noting what happened with nodejs in Bionic: > > > > https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863 > > https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1794589 > > > > Summary: nodejs incorporated the version of openssl it gets built with > > into its ABI, causing incompatibility between binary modules built in > > different places if they mismatch, contrary to ecosystem expectations. > > Upstream therefore considers[1] the openssl version that must be used > > "locked" for a particular nodejs version. But if we use the version > > upstream wants, and that differs from our "default" version, then the > > resulting co-installability conflict between the two -dev packages > > results in users complaining about that instead. > > > > It might be worth someone looking into this early in order to try to > > avoid or mitigate a recurrence of this kind of issue. > > (my apologies, this mail will likely contain quite a few links) > > I looked a little bit into this, and as of 8 hours ago, the embedded copy > of OpenSSL has been updated to version 3.0.0[0]. They have an open issue > tracking the OpenSSL 3.0 support situation[1], and their technical > committee has a document specifiying which OpenSSL release is supported > for a given NodeJS version[2]. > > According to this comment[3] it seems they don't plan on supporting > OpenSSL 3.0 in the 16.x branch, but rather in the 17.x which will have > its first release next week according to their release schedule[4]. > Sadly, the new 17.x branch isn't planned as an LTS one. > > Looking inwards, we currently ship a NodeJS version based on the 12.x > branch, and Debian seems to be planning[5] a transition towards the 14.x > branch. None of which support OpenSSL 3.0. > > Unless I'm missing something, I see the following options, in no > particular order: > > (a) Remove NodeJS from the archive. Had to be mentioned, but I don't > think it's realistic ;-) > > (b) Keep in sync with Debian, use the 14.x branch, but keep OpenSSL 1.1.1 > in the archive via a compat package. > (b') The same but using the embedded copy of OpenSSL (if even possible?). > > (c) Use NodeJS v17.x in JJ (when it's out), with OpenSSL 3.0. This would > entail > doing the transition on our own, and it basically would be EOL two > months after the JJ release. > > (d) Track the NodeJS master branch in JJ and update NodeJS to the official > version 18.0 a few days after our release of 22.04. > > (e) Use 16.x + OpenSSL3 patches. I'm not entirely sure whether this > would create the same issues as mentioned by Robie, as the support > for a linked 3.0.0 is documented in [2]. > > I feel like (b) is our safest bet. If we go this route, we'll want to > make sure that libssl-dev and libssl1.1-dev are coinstallable, as it was > apparently a painpoint in the previous OpenSSL transition. > > I welcome any other options or perspectives on the issue :) Yeah none of those seem ideal, but I can't think of anything to add to your list. A couple additional factors come to mind, although maybe you've already taken them into account. First, nodejs tutorials commonly have the reader use the platform nodejs to bootstrap to a newer nodejs for actual development. So, better to be consistent and stable than latest in greatest. Second, nodejs is in universe, so that affects its support situation differently than if it were in main. So, best not to expect very heavy maintenance activity post-release. v14 hits upstream EOL in 2023-04-30, which seems suboptimal for supportability. Initial release for v18 (final) isn't scheduled until 2022-03-19, so while that might be feasible for 22.04.1 it isn't an option for the 22.04.0 image. It looks like Fedora moved to nodejs v16 for their Fedora 35 release [0], and plan to adopt OpenSSL 3 for 36 [1], although they have already run into at least one incompatibility [2]. Anyway, makes me a bit curious about feasibility of (e). Bryce [0]: https://fedoraproject.org/wiki/Releases/35/ChangeSet#Node.js_16.x_by_default [1]: https://fedoraproject.org/wiki/Changes/OpenSSL3.0 [2]: https://www.spinics.net/lists/fedora-devel/msg291957.html > Cheers, > Simon > > [0]: > https://github.com/nodejs/node/commit/66da32c045035cf2710a48773dc6f55f00e20c40 > [1]: https://github.com/nodejs/node/issues/29817 > [2]: https://github.com/nodejs/TSC/blob/main/OpenSSL-Strategy.md > [3]: https://github.com/nodejs/node/issues/40106#issuecomment-937718359 > [4]: https://github.com/nodejs/Release#release-schedule > [5]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989266#10 > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify
Re: OpenSSL 3.0 transition plans
On Thu, Oct 7, 2021 at 10:31 AM Simon Chopin wrote: > > Hi all, > > As some of you might have surmised, we're planning to move to OpenSSL > 3.0 [0] for 22.04. This new major release brings of course some new > things, but also breaks API and ABI. If/when we get to 3.0, please do let upstream systemd know, as Ubuntu is the last blocker holding up the transition from gcrypt over to openssl in systemd. https://github.com/systemd/systemd/pull/14743#issuecomment-748078464 > > We intend to update the openssl package to 3.0.0 as soon as possible in > the 22.04 cycle, provided that all the build-rdepends of libssl-dev in > main are ready for the transition. You'll find at [1] the latest test > rebuild, where you'll find that around 35 rdeps from main, and ~180 > packages from universe fail to build. This test build has been done in > the PPA schopin/openssl-3.0.0 [2], which you can use to test your > packages against. > > If you'd like to help out (please do ;-)), I've started filing bugs > against the various packages that fail, using the tag > 'transition-openssl3-jj' [3] to track it all. Please use this tag when > working on this issue. You'll find resources to migrate codebases from > 1.1 in the OpenSSL man pages[4]. > > As stated, the transition should only take place if main is ready for > it. As far as universe is concerned, in an ideal world all the 180 > packages above would be fixed in time for the release. However, if not > so, we'll either remove the package from the release or, if *really* > necessary, would introduce a compatibility openssl-1.1 package. The > latter option is of course highly undesirable. > > When we'll upload the new version of openssl to the archive, existing > packages should still be installable as the binaries for libssl1.1 will > be kept around as long as they're depended on. However, the autopkgtests > of packages lagging in the transition, or even of their rdeps, might > start to fail if they build the tests during the autopkgtests. If that's > the case, you might want to get the package rebuilt against OpenSSL3 and > rerun the tests with all-proposed=1. > > Cheers, > Simon Chopin > > [0]: https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ > [1]: https://people.canonical.com/~schopin/rebuilds/openssl-3.0.0-impish.html > [2]: https://launchpad.net/~schopin/+archive/ubuntu/openssl-3.0.0 > [3]: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=transition-openssl3-jj > [4]: https://www.openssl.org/docs/manmaster/man7/migration_guide.html > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenSSL 3.0 transition plans
On Mon, Oct 11, 2021 at 2:48 PM Simon Chopin wrote: > > Hi Robie, > > Quoting Robie Basak (2021-10-11 12:39:00) > > I think it's worth noting what happened with nodejs in Bionic: > > > > https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863 > > https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1794589 > > > > Summary: nodejs incorporated the version of openssl it gets built with > > into its ABI, causing incompatibility between binary modules built in > > different places if they mismatch, contrary to ecosystem expectations. > > Upstream therefore considers[1] the openssl version that must be used > > "locked" for a particular nodejs version. But if we use the version > > upstream wants, and that differs from our "default" version, then the > > resulting co-installability conflict between the two -dev packages > > results in users complaining about that instead. > > > > It might be worth someone looking into this early in order to try to > > avoid or mitigate a recurrence of this kind of issue. > > (my apologies, this mail will likely contain quite a few links) > > I looked a little bit into this, and as of 8 hours ago, the embedded copy > of OpenSSL has been updated to version 3.0.0[0]. They have an open issue > tracking the OpenSSL 3.0 support situation[1], and their technical > committee has a document specifiying which OpenSSL release is supported > for a given NodeJS version[2]. > > According to this comment[3] it seems they don't plan on supporting > OpenSSL 3.0 in the 16.x branch, but rather in the 17.x which will have > its first release next week according to their release schedule[4]. > Sadly, the new 17.x branch isn't planned as an LTS one. > > Looking inwards, we currently ship a NodeJS version based on the 12.x > branch, and Debian seems to be planning[5] a transition towards the 14.x > branch. None of which support OpenSSL 3.0. > > Unless I'm missing something, I see the following options, in no > particular order: > > (a) Remove NodeJS from the archive. Had to be mentioned, but I don't > think it's realistic ;-) > > (b) Keep in sync with Debian, use the 14.x branch, but keep OpenSSL 1.1.1 > in the archive via a compat package. > (b') The same but using the embedded copy of OpenSSL (if even possible?). > (b') has been done in the past in Debian, and can be done again in Debian/Ubuntu. I'm not sure how well extensions compile when one does that and if we will still need to package nodejs-openssl headers somewhere. Doing (b') imho is less liability than packaging and providing 1.1.1 in the archive, as despite all pleas people tend to assume that they don't need to do anything and can stick with 1.1.1 for another ten years without doing any work to migrate to 3.0.0. -- Regards, Dimitri. > (c) Use NodeJS v17.x in JJ (when it's out), with OpenSSL 3.0. This would > entail > doing the transition on our own, and it basically would be EOL two > months after the JJ release. > > (d) Track the NodeJS master branch in JJ and update NodeJS to the official > version 18.0 a few days after our release of 22.04. > > (e) Use 16.x + OpenSSL3 patches. I'm not entirely sure whether this > would create the same issues as mentioned by Robie, as the support > for a linked 3.0.0 is documented in [2]. > > I feel like (b) is our safest bet. If we go this route, we'll want to > make sure that libssl-dev and libssl1.1-dev are coinstallable, as it was > apparently a painpoint in the previous OpenSSL transition. > > I welcome any other options or perspectives on the issue :) > > Cheers, > Simon > > [0]: > https://github.com/nodejs/node/commit/66da32c045035cf2710a48773dc6f55f00e20c40 > [1]: https://github.com/nodejs/node/issues/29817 > [2]: https://github.com/nodejs/TSC/blob/main/OpenSSL-Strategy.md > [3]: https://github.com/nodejs/node/issues/40106#issuecomment-937718359 > [4]: https://github.com/nodejs/Release#release-schedule > [5]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989266#10 > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenSSL 3.0 transition plans
Hi Robie, Quoting Robie Basak (2021-10-11 12:39:00) > I think it's worth noting what happened with nodejs in Bionic: > > https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863 > https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1794589 > > Summary: nodejs incorporated the version of openssl it gets built with > into its ABI, causing incompatibility between binary modules built in > different places if they mismatch, contrary to ecosystem expectations. > Upstream therefore considers[1] the openssl version that must be used > "locked" for a particular nodejs version. But if we use the version > upstream wants, and that differs from our "default" version, then the > resulting co-installability conflict between the two -dev packages > results in users complaining about that instead. > > It might be worth someone looking into this early in order to try to > avoid or mitigate a recurrence of this kind of issue. (my apologies, this mail will likely contain quite a few links) I looked a little bit into this, and as of 8 hours ago, the embedded copy of OpenSSL has been updated to version 3.0.0[0]. They have an open issue tracking the OpenSSL 3.0 support situation[1], and their technical committee has a document specifiying which OpenSSL release is supported for a given NodeJS version[2]. According to this comment[3] it seems they don't plan on supporting OpenSSL 3.0 in the 16.x branch, but rather in the 17.x which will have its first release next week according to their release schedule[4]. Sadly, the new 17.x branch isn't planned as an LTS one. Looking inwards, we currently ship a NodeJS version based on the 12.x branch, and Debian seems to be planning[5] a transition towards the 14.x branch. None of which support OpenSSL 3.0. Unless I'm missing something, I see the following options, in no particular order: (a) Remove NodeJS from the archive. Had to be mentioned, but I don't think it's realistic ;-) (b) Keep in sync with Debian, use the 14.x branch, but keep OpenSSL 1.1.1 in the archive via a compat package. (b') The same but using the embedded copy of OpenSSL (if even possible?). (c) Use NodeJS v17.x in JJ (when it's out), with OpenSSL 3.0. This would entail doing the transition on our own, and it basically would be EOL two months after the JJ release. (d) Track the NodeJS master branch in JJ and update NodeJS to the official version 18.0 a few days after our release of 22.04. (e) Use 16.x + OpenSSL3 patches. I'm not entirely sure whether this would create the same issues as mentioned by Robie, as the support for a linked 3.0.0 is documented in [2]. I feel like (b) is our safest bet. If we go this route, we'll want to make sure that libssl-dev and libssl1.1-dev are coinstallable, as it was apparently a painpoint in the previous OpenSSL transition. I welcome any other options or perspectives on the issue :) Cheers, Simon [0]: https://github.com/nodejs/node/commit/66da32c045035cf2710a48773dc6f55f00e20c40 [1]: https://github.com/nodejs/node/issues/29817 [2]: https://github.com/nodejs/TSC/blob/main/OpenSSL-Strategy.md [3]: https://github.com/nodejs/node/issues/40106#issuecomment-937718359 [4]: https://github.com/nodejs/Release#release-schedule [5]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989266#10 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenSSL 3.0 transition plans
Hi Simon, Thank you for working on this! On Sat, Oct 02, 2021 at 02:01:10AM -0700, Simon Chopin wrote: > As stated, the transition should only take place if main is ready for > it. As far as universe is concerned, in an ideal world all the 180 > packages above would be fixed in time for the release. However, if not > so, we'll either remove the package from the release or, if *really* > necessary, would introduce a compatibility openssl-1.1 package. The > latter option is of course highly undesirable. I think it's worth noting what happened with nodejs in Bionic: https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863 https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1794589 Summary: nodejs incorporated the version of openssl it gets built with into its ABI, causing incompatibility between binary modules built in different places if they mismatch, contrary to ecosystem expectations. Upstream therefore considers[1] the openssl version that must be used "locked" for a particular nodejs version. But if we use the version upstream wants, and that differs from our "default" version, then the resulting co-installability conflict between the two -dev packages results in users complaining about that instead. It might be worth someone looking into this early in order to try to avoid or mitigate a recurrence of this kind of issue. HTH! Robie [1] I don't know if this is still the case. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
