NB: attempting to re-send with a slightly different e-mail address that might make my mails pass list moderation automatically (no idea why I receive mails to a From: which isn't the one I'm subscribed with)
On Mon, Dec 04, 2023, Dimitri John Ledkov wrote: > On Mon, 4 Dec 2023 at 12:34, Adrien Nader <adr...@notk.org> wrote: > > I concur with you here: I believe that using 3.0 in Noble is > > problematic. However I think we do not have a good solution at the > > moment. All solutions have serious drawbacks. > > > > For the record, I started this thread when I was about to update openssl > > to 3.1 in whichever release was under development back then. And at some > > point I realized things were not going to work out well. One thing > > that's very difficult is that when Ubuntu non-LTS gets a new openssl > > version, we have no idea on which openssl version we'll end up for our > > next LTS. > > > > This can improve with openssl having a release schedule but > > what we really need is the LTS schedule. This is really a recent change > > for openssl and I haven't had time to interact with upstream since 3.2 > > was released (before that I was monitoring how that release was going). > > Strictly speaking, there could be openssl LTS releases every 4.5 years > > and that would be really painful. Less than every 2 years seems > > doubtful. I would expect something between 2 and 4 years: 2, 2.5, 3, > > 3.5, 4; that's a lot of possibilities. > > > > (I'll draft something on pen and paper and see if a two-years and > > three-years cadence for LTS would be sensible based on the 5=4+1 years > > of openssl LTS schedule) > > > > We should first engage with upstream on this. I've had absolutely no > > time since mid-October but I hope I can make a bit of room for that > > soon. At least we should check if this has been brought up recently. > > https://www.openssl.org/blog/blog/2023/11/23/OpenSSL32/ > """ > The next feature release after OpenSSL 3.2 will be OpenSSL 3.3, which > will be released no later than 30 April 2024. This release is expected > to include QUIC server support. The determination of what other > features will be shipped in OpenSSL 3.3 is ongoing and will be decided > by our recently announced Release Steering Committee. > """ > Thus timing wise it seems doable to ship noble with v3.3, unless things slip > > Looking at feature list between v3.0 and v3.2, we absolutely desire: > > * Support for client side QUIC, including support for multiple streams > (RFC 9000) That one was at or near the top of openssl changes that made me want to update but it turns out it's a new API and therefore not compatible with one of the existing QUIC libraries. As such, openssl might not be where to look for when it comes to QUIC support. (I don't know how's our support for QUIC currently) > * Support for Ed25519ctx, Ed25519ph and Ed448ph in addition to > existing support for Ed25519 and Ed448 (RFC 8032) > * Support for deterministic ECDSA signatures (RFC 6979) > * Support for the Argon2 KDF, along with supporting thread pool > functionality (RFC 9106) > * Support for TCP Fast Open on Linux, macOS and FreeBSD, where enabled > and supported (RFC 7413) > * Support for TLS certificate compression, including library support > for zlib, Brotli and zstd (RFC 8879) > > Without these features, most users will seek out to get that, and will > find ways to get it, without running our build of OpenSSL, exposing > them to security risks. > > Can you backport all of that to the v3.0 series? how is that going to > make it look any much different from shipping v3.2 or v3.3? This has been my concern too: I don't want us to end up with a franken-openssl. I'm now very confident this won't happen, in particular for Noble. The only question is therefore how needed are these features. If you look at the changes in openssl 3.x versions, you'll always see a long list of change at a pretty rapid pace. I'm sure 3.3 will include many features we'll want too. I have absolutely no doubt about it. But what's the point in shipping something we cannot support? Today we can't really support an non-LTS openssl version. We wouldn't have this conversation if openssl were in universe but it's not, it's in main. > https://www.openssl.org/policies/releasestrat.html > """ > We may designate a release as a Long Term Support (LTS) release. LTS > releases will be supported for at least five years and we will specify > one at least every four years. Non-LTS releases will be supported for > at least two years. > """ I remembered only one year for non-LTS but like for LTS, that final year is security-only. > If synergy and coordination is a serious blocker, and v3.3 is not > designated as upstream longterm, we should plan for in-noble upgrade > to a later upstream - however painful that is. Although API and ABI > stability guarantees have been improved upstream post v3.0 release. > Maybe it is worth to run abi & api checks against jammy using v3.2. > Also given the previous release date of v3.0 the upstream OpenSSL > longterm might not arrive until 2025. Do you really want to support > v3.0 openssl in noble, with many users opting not to use it at all, > and suffer support fallout from that? As I mentioned earlier, I have been trying to SRU a few changes with a moonshot of being able to update across releases. Do an SRU, get an MRE, manager to get an RE (MRE without the "micro"). What did I learn? ABI (and API I guess) was stable between jammy and lunar or mantic. Pretty good. However the main teaching is that I could update the SRU wiki page with tons of things to check for. For instance, in that SRU there was initially 4 patches series. While working on SRU'ing one to fix blowfish ECB/OCB/XYZ encryption in jammy, I noticed that the bug had created a situation where these BF encryptions and decryptions were incompatible with the rest of the world but compatible within Jammy, and that fixing it would restore compatibility with the rest of the world but break it between pre-upgrade and post-upgrade Jammy. Worse: this is used both for encrypting and decrypting data at rest but also data in transit. And someone reported that issue a couple weeks ago with a slightly different scenario. No matter what we do, there are incompatibilities. The SRU policy is to not potentially break workflows. The issue appeared in 3.0.0, we shipped 3.0.2 in Jammy, and it was fixed in 3.0.4 (shipped in kinetic). I would be surprised that is the only incompatible change with 3.0.z, let alone 3.y.z. At least there aren't more changes in 3.0.z than can be tracked but even then, there's a lot of things to track. Moreover, 3.2 on Jammy without these breaking changes would also be quite surprising for users. As I said: I think it would be interesting to have the most recent version but we're not able to do the amount of work required. Probably at least by a factor of 10. > Because we cannot upgrade OpenSSL only every 4 years, that's way too > slow for the speed of performance gains and improvements in TLS. Now that I've finally eaten, I took the time to write down a support schedule for openssl's upstream. They would have to support _five_ releases at the same time once the pace is set. I'm also not sure who runs a non-LTS _and_ needs two years or support. That lines up well enough with a release a year but not really with two releases a year. I think the most sensible thing to do is approach upstream and question their cadence and support duration. A release every six months is fine and I'm under the impression they went for time-based releases after having too many delays with 3.x releases. But the support duration is another matter: six months and six months security-only seems a better fit for their release cadence, with only three releases requiring support. I hope the time freed by this would make it possible to release an LTS every two years instead. > For interim releases, we should ship the latest OpenSSL release and > ship the upstream point releases fixes, as that effectively tests > things for the next LTS and the support timeframes overlap there, > meaning it should become at no additional burden for the security > team. The issue remains the same: if we do that, we are likely to ship a non-LTS in our LTS. This will certainly happen starting with 24.10 since there will be another openssl LTS by 26.04 but without such a guarantee, this is equivalent to using a non-LTS in our LTS. -- 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
