Choice of the openssl version for 23.10 and 24.04

[Dimitri John Ledkov]

On Mon, 4 Dec 2023 at 09:28, Adrien Nader <adrien at notk.org> wrote:
>
> On Mon, Dec 04, 2023, 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.
>
> The issue is that we do not know when will be the next openssl LTS. We

That's irrelevant. Once Ubuntu release goes stable, we no longer apply
full upstream point releases, and create our own stream of security
and stable fixes anyway.
Our timelines of support are also longer than either shorter or longer
upstream support timelines.

> can safely bet there will be one before 26.04 and update to the most
> recent version for 24.10 (since by 26.04, the current LTS won't be
> supported anymore). However we can't really bet there will be one by
> 24.04 and even if there were, there probably wouldn't be a new one in
> time by 26.04.
>
> What you are asking for is equivalent to not using openssl LTS releases
> for Ubuntu LTS releases.

Yes.

> There are many more non-LTS releases so we're
> more likely to end up with a non-LTS version.
>
> Openssl time-based releases are very very recent.

We did ship the first KDE time-based release when it came out for the
first time.

> This was announced
> late August and only one version was released under this model so far.
> It wasn't even on time. The delay was fairly small, especially for a
> first version using this model (and a change mid-cycle). I think they
> need a bit more time. Will they be late again? Will they continue this
> scheme? What else? I don't expect openssl upstream can answer these;
> they don't have enough hindsight yet.
>
> We talked about creating a new "openssl" package that is whatever the
> most recent version is (in universe, and probably with no ESM-guarantee
> attached somehow). This might need a bit of fiddling with packaging
> though and in any case, I've had absolutely no time to do that so far.
>
> Would such a package fit the needs you see?

Only one version, the latest openssl, in every Ubuntu release, going forward.

Shipping two openssl in the archive is extremely difficult and ends up
being unusable. Devel packages previously have not been coinstallable
and even if they are it is impossible to get a consistent build
environment that can build either or both openssl versions, leading to
extremely bad user experience. For example inability to compile
scripting language native extensions as part of container builds and
the like - prime past example
https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1794589

> Otherwise, really, I think
> your question is equivalent to not using openssl LTS releases which
> would be a big departure from the current position.

It is not a departure - as we have done that before. It will be an
overall performance saving by reducing the number of HWE SRUs that
would end up doing anyway. At the cost of increased security
maintenance - but even that is not too obvious, as often security
fixes affect only a subset of upstream series.

We did ship bionic with openssl 1.1.0 for example.

My biggest worry is that by mid 2025, when production workloads
migrate to Noble by default, and if Noble ships with Openssl 3.0 it
will be a 4 year old release of OpenSSL which is unacceptable.

Irrespective of upstream longterm status, we must upgrade OpenSSL to a
new upstream release between two Ubuntu LTS releases.

-- 
Dimitri

Sent from Ubuntu Pro
https://ubuntu.com/pro