On Tue, May 16, 2023, Marc Deslauriers wrote: > On 2023-05-15 05:18, Adrien Nader wrote: > > Hello, > > > > Ubuntu currently ships openssl 3.0. Debian will release with 3.0. > > > > Debian experimental contains 3.1. Openssl 3.1 has been out for a couple > > months. It seemed natural to switch to 3.1 which contains a number of > > interesting changes including fixes for performance regressions except > > that... > > > > Quoting https://www.openssl.org/policies/releasestrat.html : > > > > - Version 3.1 will be supported until 2025-03-14 > > - Version 3.0 will be supported until 2026-09-07 (LTS). > > > > The support for 3.1 spans two years while the support for 3.0 spans 5 > > years since it's an LTS. > > > > If the openssl teams keeps the same cadence (I love extrapolating with > > only two data points, it's much simpler), then 3.2 could be released > > September 2024 and it could be just in time to be included in 24.10 but > > obviously not 24.04. There's also no indication at the moment that 3.2 > > would be an LTS release. As for 3.3, it would be released March 2026 and > > that would still be early enough to make it the next LTS. > > > > As I said, these dates are extrapolation based on the 3.0 to 3.1 release > > and I haven't seen communication from the openssl team about their > > roadmap besides that they had to remove it at some point because it > > needed more work. It's seems unlikely that the result of "more work" is > > as simple as "release every 18 months". > > > > In any case, it seems unlikely that 3.2 is released in time for 24.04 > > feature freeze AND is an LTS. I'm going to raise this topic on the > > openssl issue tracker but I wanted to begin the discussion here since > > the same issue is likely to pop again in the future. > > > > In short: > > > > In 24.04, do we want to include a release of openssl that will be > > supported for "at least two years", possibly starting a year before our > > release, or do we want to include a release that will be supported for > > "at least five years", possibly starting two years before our release. > > I'd rather we stick with an OpenSSL LTS release, as that is possibly what > others distros will be using and we will be able to collaborate on fixes > once the upstream support goes away.
OK. I don't have strong opinions on this, especially since I'm not the one who will be pushing security updates. My main concern is a possible backlash, especially since 3.0's performance is sometimes a lot worse than 1.1's and that there won't be a newer version in a Ubuntu LTS before 26.04 ( https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544 is one example ). > > Bonus questions: > > > > What do we do when the support on the openssl side ends but there's > > three more years of support for our LTS releases? > > We do like we do for all the other packages in our archive, we backport > patches to the unsupported version. (And we support our LTS releases for a > minimum of 10 years now...) I had forgotten this was now 10 years; I was too set on Bionic's schedule. One advantage of using 3.0 is that it would be the same version as in Jammy. Maybe even 26.04 will use it too... > > > > In case we SRU newer versions of openssl, will we attempt to maintain > > the same behaviour? (I wanted to ask that question but the answer is > > probably not a yes/no: a best-effort policy might make more sense) > > > > We don't SRU newer versions of OpenSSL. The attempts we've made in the past > to SRU a minor point release resulted in hundreds of fixes required all over > the archive and caused regressions for users. Backporting security fixes and > specific bug fixes is the best approach. Thanks for the explanation. -- Adrien -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
