>Hello ubuntu-devel,
Hi Ravi,
>I am writing to get your opinion on the version of OpenSSL in Ubuntu 26.04 LTS.
>
>OpenSSL 3.5 is the current version in Resolute Raccoon release pocket.
>From now on, only bug fixes and security patches will be applied to
>3.5
>It is an LTS release, it will be supported by upstream until
>2030-04-08. There is a good overlap with 26.04 End of Standard Support
>until 2031-04.
>
>OpenSSL 3.6 is the current upstream release
>(https://github.com/openssl/openssl/releases/tag/openssl-3.6.0). It is
>a Non-LTS release, and it will be full supported for 13 months
>(2026-11)
>
>OpenSSL 4.0 is the next upstream release. It is also a Non-LTS, and It
>will introduce API/ABI incompatible changes.
>
>26.04 Timeline
>- Oct 1, 2025 OpenSSL 3.6 release
>- February 19, 2026 Ubuntu Feature Freeze
>- March 25, 2026 OpenSSL 4.0 Beta release (estimated)
>- April 7, 2026 OpenSSL 4.0 Final release
>- April 16, 2026 Ubuntu Final Freeze
>
>I am ruling out 4.0 since it will not be Feature Complete before
>Ubuntu Feature Freeze, there isn't enough time for reverse dependences
>to adapt to the breaking API/ABI changes, and we want to avoid a major
>version bump just before an LTS. You can find a preview of 4.0
>breaking changes under milestone
>https://github.com/openssl/openssl/milestone/24.
>
>My proposal is to stay on 3.5 for 26.04 LTS to take advantage of the
>upstream LTS, and move to 4.0 directly in 26.10. To make sure we are
>not falling behind, I plan to do a test rebuild of 3.6 in a PPA.
>
>The downside is missing out on latest features from 3.6. Please let me
>know what you think.
>
>References:
>https://openssl-library.org/policies/releasestrat/index.html
>https://openssl-library.org/roadmap/index.html
>https://discourse.ubuntu.com/t/resolute-raccoon-release-schedule/47198
>
>Regards
>Ravi
As it is described in the upstream roadmap in your references
(https://openssl-library.org/roadmap/index.html), the upstream project
intends to have "a new [openSSL] LTS version designated at least every
two years.", which seems to align quite well with our LTS cycles.
In the last couple LTS cycles, I would often check for potential LTS
releases of packages before merging them. From a maintenance
perspective, I agree with the path you are proposing, i.e., staying in
3.5 so we can benefit from the upstream LTS support.
From a strategic perspective I would also take a look at why the minor
version was bumped to 3.6 before deciding to stick to 3.5.
https://github.com/openssl/openssl/releases/tag/openssl-3.6.0 lists the
significant changes for openssl 3.6. From that list, they are mostly
compliance/new features. These are the ones I found to be most relevant:
Added NIST security categories for PKEY objects.
Added support for EVP_SKEY opaque symmetric key objects to the key
derivation and key exchange provider methods. Added EVP_KDF_CTX_set_SKEY(),
EVP_KDF_derive_SKEY(), and EVP_PKEY_derive_SKEY() functions.
Added LMS signature verification support as per [SP 800-208]..
This support is present in both the FIPS and default providers.
Added support for FIPS 186-5 deterministic ECDSA signature
generation to the FIPS provider.
It seems to be fair to stick to 3.5 then? Still, it may be a good idea
to involve the security team since they would be in a better position to
weight in from both stand points (providing support for the non LTS vs
having the new compliance features).
--
Athos Ribeiro
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
