On Wed, May 17, 2023, Dimitri John Ledkov wrote: > We had similar dilemma around focal release. And I did SRU one off upgrade > from 1.1.0 to 1.1.1. it was a minor disaster. (As in like the sad > depressing songs in A minor scale). > > It is best to stick to one openssl version in a release. > > It is best to stick to longer supported one. > > It is best not to chase minor ones that nobody will use or want long term.
Note that experimental currently has 3.1 (yes, it's experimental and it doesn't have to go anywhere else). I need to get in touch with the team on the debian side and ask them their plans regarding versions support. > Mantic is open for development, and usually optimisations are fairly > standalone. Even if upstream is not backporting performance optimisations - > we can do so, and have done that for x86, s390x, ppc64el, arm64 in the > past. If there are high priority optimisations that we want in our openssl > we should attempt backports of those onto current openssl release we ship > in mantic. > > Note, we would have to then monitor for regressions & security fixes to > those optimisation backports. Unfortunately, the optimisations currently being added don't seem very standalone since they're frequently architectural ones (see the end of this message). Even benchmarking might be non-trivial. For instance, one of the current issue seem to be locking and lock contention: properly benchmarking such changes requires a good test environment and possibly extra hardware. I had thought about making a PPA for newer versions in order to make it easier for people to execute their own benchmark with them. That's maybe the only way to gather more feedback on the performance changes. > On Wed, 17 May 2023, 21:35 Adrien Nader, <adr...@notk.org> wrote: > > > 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 ). > > > > Can this be cherry picked into mantic? > The changes is +328,-127 lines. I'm not even sure it doesn't depend on other changes (read: I think it does). If you look at the discussion at https://github.com/openssl/openssl/issues/20286 (it's fairly long), you will see there are other proposed changes and it's not over yet. There are also other discussions with their own set of patches too. As far as I understand, a lot of this is due to the new software architecture in openssl 3. It's slower than 1.1 due to the design and since we're early in the life of 3.y, there are many rather-low-hanging fruits. This causes a lot of churn. Overall this is probably a lot of work: on the order of weeks if not months to catch up and several days a month to keep up-to-datei (there are 1607 commits between 3.0.0 and 3.1.0). It doesn't look like upstream is trying to include performance improvements in 3.0.z releases. -- 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
