It's less about bug completeness and more about the risks of breaking users. The general rule for the whole distribution is backporting specific fixes for specific bugs; however, there's a handful of packages where that's not feasible, desired, etc.
Firefox and Chromium are the most obvious cases of wanting the same, recent, version, on all supported releases. The upstream developers for these projects have way more resources and way more comprehensive test suites than we could ever hope to achieve ourselves, and they've got loads of experience making frequent releases. MySQL, MariaDB, PostgreSQL are common for "the most recent version of the release that was used at the time of release" (or something like that; it's an ugly mouthful). Moving from MySQL 5.5 to 8 would be a huge jump, but 5.5.32 to 5.5.36 to 5.5.40 etc shouldn't be a big deal. (Alas, it is. LP:2019203.) These are also far more complex than we can realistically engineer ourselves. We've done full-version jumps with Samba before; some of their security fixes involve hundreds of patches with huge refactoring. There's no good choices with Samba. The risks of backporting are huge, the opportunity costs are even larger, and if we backport that much, we'll wind up with software that nobody is familiar with. So, we will sometimes ship entirely new versions, and just deal with all the fallout from regressions. OpenSSL is a challenging case. It'd be ideal to run the same version as upstream, so when there's issues, there's a much larger community working on them. Perhaps the OpenSSL upstream developers have an extensive enough test suite today to reduce the risks of using entirely new versions. I know that historically we've found some issues with security patches via our testing that the OpenSSL upstream testing missed. I also know that our testing is focused on what ships in our distribution, it doesn't test the wide world of propriety software or not-yet-packaged software, so we know we have blind spots. If we explore shipping upstream OpenSSL packages, I'd really like to see it trialed in our 'interim' releases: eg, ship an OpenSSL update halfway through the support cycle for 23.04, 23.10, 24.10, 25.04, 25.10, and if those all go well, consider it for 26.04 and future releases. There's way fewer users of our interim releases (which is both a benefit and a curse, here) and the consequences of a problem are thus constrained. Users expect (if not appreciate) breaking changes at release points. They don't expect (and detest) such changes in LTS releases. Given the foundational importance of OpenSSL, I think it makes sense to go very slowly in testing such a hypothetical change. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2019970 Title: OpenSSL 3.0.2 crash in Ubuntu 22.04.2 LTS Status in openssl package in Ubuntu: Incomplete Bug description: Full bug report at https://github.com/openssl/openssl/issues/20981 No upstream impact: OpenSSL 3.0.9-dev does not contain the problem any more. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2019970/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
