Hi Ravi, >From the Security Standards (FIPS, et al...) side, we agree that sticking to 3.5 is the best course of action. Like you said, the timelines align perfectly. We also have the benefit of shipping a release that has had time to be production hardened and for bugs to be fixed.
Like Athos suggested, we looked into the changes between version 3.5 and 3.6 and we still think it makes sense to keep 3.5. There are some changes that will need to be included in our FIPS modules but we will handle backporting them. Cheers, On Tue, Oct 21, 2025 at 8:44 AM Ravi Kant Sharma <[email protected]> wrote: > Hi Athos, thanks a lot for your input. > > I have added secuity@ubuntu to the thread. > > I want to add https://launchpad.net/~canonical-security-certification > as well, I am not sure what is the best way to reach them. > > Regards > Ravi > > On Tue, Oct 21, 2025 at 3:52 AM Athos Ribeiro > <[email protected]> wrote: > > > > 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 > -- [image: Canonical-20th-anniversary] João Gomes Linux Cryptography and Security Engineer Email: [email protected] Location: Portugal canonical.com ubuntu.com
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
