On Mon, Oct 20, 2025 at 12:27:41PM +0200, Ravi Kant Sharma wrote:
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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
