Draft a policy/strategy for stable branches

[maugustosilva]

With Keylime now packaged as part of RHEL (9.1) and SLES (15) among other distributions, the need for stable releases becomes apparent.

To exemplify the problem, RHEL 9.1 is expected to ship Keylime 6.7.X for the remainder of its maintenance cycle (several years). A Keylime stable release 6.7 shall be kept in order to allow the incorporation of bug fixes and, optionally, backported features as needed.

Will provide a PR for https://github.com/keylime/keylime/blob/master/RELEASE.md

[stefanberger]

Considering how many we are, I would suggest to only backport bugfixes.

[THS-on]

The big question is on how we deal with backports once we changed the internal architecture significantly.
Similar thing goes with parsers, the measured boot attestation will not work with many newer shims if not shipping at least tpm2-tools version 5.4.

Do we want to differentiate between agent and server components? I think it is probably easier to keep a stable branch for the agent than it is for the server side.

If we officially promote 6.7 to a stable release, then we have the issue to maintain the Python agent still until we EOL that version and I don't if we have the capacity to do that.

[aplanas]

If we officially promote 6.7 to a stable release, then we have the issue to maintain the Python agent still until we EOL that version and I don't if we have the capacity to do that.

That is a good point ... @maugustosilva does RHEL 9.1 also include the Rust agent?

Doing this properly it is always tricky and IMHO we should create a easy rules in the project, so downstream (RH, SUSE, etc) will have clear expectations.

For example, in some projects there is a LTS version, with a life time of X years, and usually one or two of those LTS are active at a given time. This can be a bit overkill for Keylime.

Other projects had a fixed cadence for release, and they support (fixes only) the last one or two releases. This model seems more appropriate for Keylime, as a backport should be more easy if the time is close.

With this a downstream can make decisions of what Keylime version to use, and expect some time when the project itself will backport fixes in new minor releases, and some other time when the patches will live in the package only.

For example, if we make a release every 6 months, and we support the last 2 releases, this will make 18 months of upstream support for a specific version, and after that the downstream project needs to update the package or backport fixes.

On the other side, if we incentive the deployment of the verifier + registrar + tenant (what is Keylime since 7.0) as a container, and the agent as an installable package, we can reach different conclusions. For example, we should be able to move fast the control plane without taking care of breaking changes in the code, and prioritize the stability of the agent and the extend the support of multiple agent version in the network.

Considering that there will be a big redesign of the Keylime architecture, this last option will have some advantages.

[stefanberger]

The big question is on how we deal with backports once we changed the internal architecture significantly.

Exactly. Other projects, such as Linux, Libvirt, and QEMU for example, only ever backport bugfixes to older branches in their repos. What distros do in their packages is a different story. This way the projects can make progress adding new features and not worrying about backporting. How would we deal with monthly releases and the possibility that different distros package a snapshot of keylime at different times?

We will need to fork the test suite as well once it starts testing things we don't have in 6.x.y. for example.

[maugustosilva]

Trying to address most of the (all pertinent) questions:

1. This was originally a request from Red Hat (@ansasaki @mpeters). AFAIK, RHEL 9.1 ships the rust agent, but server side will be kept at 6.7.x.
2. Addressing @stefanberger @THS-on concerns. The initial agreement is that the maintainer (i.e., Red Hat, SuSe, Canonical et al) would be in charge of both testing and backporting (both bug fixes and features).
3. Back to @aplanas point. I am arguing that we should "support" (and test) only the most current version. I also consider any model where "we" (Keylime) fold our efforts into "LTS versions" to be overkill (and not technically feasible).

[aplanas]

The initial agreement is that the maintainer (i.e., Red Hat, SuSe, Canonical et al) would be in charge of both testing and backporting (both bug fixes and features).

We are talking here a backport into the Keylime 6.7 branch, or into the distribution package (as a .patch file)?

I am arguing that we should "support" (and test) only the most current version

I personally like this one. We can drop the LTS and the n-1, n-2 models, and support only one release (not different of what we are doing now, IIUC)

[THS-on]

To summarize the discussion from yesterday:

• We will not create a stable branch for 6.7.X. As discussed with @ansasaki they will handle fixes in the distribution.
• For now we will only support the latest version and maybe consider the idea of best effort stable branch (e.g supported until n+2 is released) once the move from tpm2-tools is done.
• Discussion for an official stable versions is delayed until a freeze happens in one of the distributions that packages Keylime. @aplanas when is the next freeze in SLE?

[aplanas]

@aplanas when is the next freeze in SLE?

We should be good. Moving the control plane into a container help us to decouple from the SLE release scheduler. The freeze of keylime should be done when it is naturally ready.