Choice of the openssl version for 23.10 and 24.04

[Marc Deslauriers]

On 2023-12-04 04:05, Dimitri John Ledkov wrote:
> Hi,
> 
> On Fri, 20 Oct 2023 at 15:35, Adrien Nader <adrien at notk.org> wrote:
>>
>> On Fri, Oct 20, 2023, Adrien Nader wrote:
>>> Hi,
>>>
>>> A few weeks ago, openssl maintainers announced moving to a time-based
>>> release (April and October):
>>>
>>> https://www.openssl.org/blog/blog/2023/09/29/OpenSSL-Update-ICMC23/
>>>
>>>> Key takeaway 3 : Time Based Release Policy
>>>> We’re transitioning to time-based releases. This shift ensures
>>>> predictability, allowing our users and developers to plan better and
>>>> benefit from timely updates. The releases will be scheduled every
>>>> April and October.
>>>
>>> Based on this and the openssl 3.0 release date, I'd expect a new LTS
>>> version to be released (almost) in time for 26.04 but not for 24.04.
>>>
>>> *IF* an openssl LTS release is out in April 26.04, we might want to
>>> track the corresponding openssl git branch during the 26.04 release in
>>> order to be able to ship it. This is more than two years away however
>>> and a lot can happen until then. I don't have a crystal ball
>>> unfortunately. In any case, we'll know if the planned and the actual
>>> release cadence and calendar match.
>>
>> Dimitri asked me for some more details so I dug a bit more. It's
>> actually better explained in a better blog post from late August:
>>
>> https://www.openssl.org/blog/blog/2023/08/27/steps-forward
>>
>>> We’re also shifting how we release the OpenSSL library. We’ve adopted
>>> a time-based release policy, with releases every April and October.
>>> After our 3.2 release in October, our 3.3 release in April next year
>>> will be our first time-based release, marking our initial venture into
>>> this approach.
>>
>> And the release policy has been updated too:
>>
>> https://www.openssl.org/policies/general/release-policy.html
>>
>>> Planning: Continuous process, provides input to the Release Definition phase.
>>> Release Definition: Defines release backlog, lasts up to 4 weeks.
>>> Development: Execution of the release backlog, spans from 20 to 24 weeks.
>>> Release: Addressing issues discovered by the community in pre-releases. Up to 6 weeks.
>>> Support: A support phase.
>>
>> If they follow their plan, we'd therefore have pre-release versions
>> several weeks before Ubuntu releases. Of course, feature freeze
>> concerns apply if the pre-release isn't out in time.
>>
>> That's all I've seen so far (OK, I didn't dig that much). We'll see very
>> soon how that turns out in practice for the 3.2 release.
> 
> With every other major piece of our dependencies, we have committed to
> picking up regular time based releases which fit our schedule.
> This includes things like GNOME, KDE, OpenStack, GCC.
> I think we should commit to picking up the latest OpenSSL for every
> Ubuntu release going forward.
> 3.2 has been released, albeit in late November, and we should show
> good will and encourage OpenSSL to stick to their new time based
> releases.
> 
> Can we please start the upgrade of OpenSSL to 3.2?
> 
> And then if OpenSSL 3.3 is released in early April, pick that up as
> well for 24.04. If the new cadence for 3.3 means May, pick it up for
> the 24.10 instead.
> 

Please don't ship the next LTS release with a non-LTS version of OpenSSL. 
Maintaining security updates to OpenSSL is difficult enough as it is. It would 
be even more difficult to do so with a throw-away version that no other distro 
is going to maintain long-term. The only way this works is if we use the same 
version as others so we can collaborate on updates.

Marc.