F36 Change: Keylime subpackaging and agent alternatives (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Keylime_subpackaging_and_agent_altern...

== Summary ==
The [https://src.fedoraproject.org/rpms/keylime keylime] package will
be split into subpackages per role (agent, registrar, verifier, and
admin components), while allowing the alternative agent implementation
in Rust.

== Owner ==
* Name: [[User:Scorreia| Sergio Correia]]
* Email: [e-mail]

* Name: [[User:Ueno| Daiki Ueno]]
* Email: [e-mail]

== Detailed Description ==
The current [https://keylime.dev/ Keylime] package available in Fedora
provides all the components as a single package. To support the usage
scenarios where only agent or management component is deployed on a
specific host, we plan to split the package into subpackages per role.
This change also enables the alternative Keylime agent implementation
in Rust, which will eventually be preferred over the Python
implementation.

== Benefit to Fedora ==
This makes it easier to deploy Keylime agent in IoT or Fedora CoreOS
spins and thus enable remote attestation without installing full
dependencies of Keylime.

== Scope ==
* Proposal owners:
** The keylime package will provide subpackages (keylime-agent,
keylime-registrar, etc)
** The keylime package will be a meta package that will install all
the subpackages
** The Rust based [https://github.com/keylime/rust-keylime agent] will
be packaged along with its build dependencies
** Both keylime-agent implementations, one written in Python, the
other written in Rust, will be selectively installable through
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
alternatives] or a similar mechanism

* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] N/A (not a System Wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==

The keylime package will remain as a meta package for the
compatibility with the current packaging.

== How To Test ==
# Make sure that your systems meet the requirement to run either
Keylime agent or other components, as described in the
[https://keylime-docs.readthedocs.io/en/latest/ documentation]
# Install the subpackages individually and see if they function as expected
# Install the meta package (keylime) and see if it pulls all the subpackages
# Selectively install a package that provides the keylime-agent
functionality: either rust-keylime_agent (Rust-based) or
(python-)keylime-agent (Python-based), and see if they do not
interfere with each other
# If alternatives is used, check that both packages can simultaneously
exist on the same system and the user can switch the implementation
with the alternative --set command

== User Experience ==
No visible change should be observed by the existing users.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No

== Documentation ==
N/A (not a System Wide Change)

[Neal Gompa]

On Fri, Dec 17, 2021 at 5:45 AM Ben Cotton  wrote:
> https://fedoraproject.org/wiki/Changes/Keylime_subpackaging_and_agent_altern...
>
> == Summary ==
> The [https://src.fedoraproject.org/rpms/keylime keylime] package will
> be split into subpackages per role (agent, registrar, verifier, and
> admin components), while allowing the alternative agent implementation
> in Rust.
>
> == Owner ==
>
> Name: [[User:Scorreia| Sergio Correia]]
>
> Email: [e-mail]
>
> Name: [[User:Ueno| Daiki Ueno]]
>
> Email: [e-mail]
>
> == Detailed Description ==
> The current [https://keylime.dev/ Keylime] package available in Fedora
> provides all the components as a single package. To support the usage
> scenarios where only agent or management component is deployed on a
> specific host, we plan to split the package into subpackages per role.
> This change also enables the alternative Keylime agent implementation
> in Rust, which will eventually be preferred over the Python
> implementation.
>
> == Benefit to Fedora ==
> This makes it easier to deploy Keylime agent in IoT or Fedora CoreOS
> spins and thus enable remote attestation without installing full
> dependencies of Keylime.
>
> == Scope ==
> Proposal owners:
>
> ** The keylime package will provide subpackages (keylime-agent,
> keylime-registrar, etc)
> ** The keylime package will be a meta package that will install all
> the subpackages
> ** The Rust based [https://github.com/keylime/rust-keylime agent] will
> be packaged along with its build dependencies
> ** Both keylime-agent implementations, one written in Python, the
> other written in Rust, will be selectively installable through
> [https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
> alternatives] or a similar mechanism

Alternatives only make sense if parallel installability is desirable.
It doesn't sound like that is the case for this situation.

Instead, you probably want to leverage RPM's installable alternatives
framework, which we use for PipeWire/PulseAudio and
pipewire-media-session/wireplumber.

For PipeWire/PulseAudio, the pipewire-pulseaudio and pulseaudio
packages had the following stanzas added:

Provides: pulseaudio-daemon
Conflicts: pulseaudio-daemon

For pipewire-media-session/wireplumber, those packages had the
following stanzas added:

Provides: pipewire-session-manager
Conflicts: pipewire-session-manager

The Provides+Conflicts on a single virtual name makes it so RPM knows
that those packages are equivalent providers, but only one of them can
be present on a system at a time. Attempting to install the other
would trigger a Conflicts, and you'd need to use "dnf swap" to switch
implementations.

For your case, each Keylime agent package would have the following stanzas:

Provides: keylime-tpm-agent
Conflicts: keylime-tpm-agent

Those two stanzas tell RPM that keylime-agent-python and
keylime-agent-rust are equivalent, but conflicting providers of
"keylime-tpm-agent" and will only allow one or the other.

[Sergio Correia]

Hello and apologies for the delayed response; I have been out of
office for a couple of weeks.

On Fri, Dec 17, 2021 at 8:00 AM Neal Gompa  wrote:
> On Fri, Dec 17, 2021 at 5:45 AM Ben Cotton  wrote:
> > https://fedoraproject.org/wiki/Changes/Keylime_subpackaging_and_agent_altern...
> >
> > == Summary ==
> > The [https://src.fedoraproject.org/rpms/keylime keylime] package will
> > be split into subpackages per role (agent, registrar, verifier, and
> > admin components), while allowing the alternative agent implementation
> > in Rust.
> >
> > == Owner ==
> >
> > Name: [[User:Scorreia| Sergio Correia]]
> >
> > Email: [e-mail]
> >
> > Name: [[User:Ueno| Daiki Ueno]]
> >
> > Email: [e-mail]
> >
> > == Detailed Description ==
> > The current [https://keylime.dev/ Keylime] package available in Fedora
> > provides all the components as a single package. To support the usage
> > scenarios where only agent or management component is deployed on a
> > specific host, we plan to split the package into subpackages per role.
> > This change also enables the alternative Keylime agent implementation
> > in Rust, which will eventually be preferred over the Python
> > implementation.
> >
> > == Benefit to Fedora ==
> > This makes it easier to deploy Keylime agent in IoT or Fedora CoreOS
> > spins and thus enable remote attestation without installing full
> > dependencies of Keylime.
> >
> > == Scope ==
> > Proposal owners:
> >
> > ** The keylime package will provide subpackages (keylime-agent,
> > keylime-registrar, etc)
> > ** The keylime package will be a meta package that will install all
> > the subpackages
> > ** The Rust based [https://github.com/keylime/rust-keylime agent] will
> > be packaged along with its build dependencies
> > ** Both keylime-agent implementations, one written in Python, the
> > other written in Rust, will be selectively installable through
> > [https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
> > alternatives] or a similar mechanism
>
> Alternatives only make sense if parallel installability is desirable.
> It doesn't sound like that is the case for this situation.
>
> Instead, you probably want to leverage RPM's installable alternatives
> framework, which we use for PipeWire/PulseAudio and
> pipewire-media-session/wireplumber.

Yeah, you are right; looking at your pipewire/pulseaudio example, it
looks like what we want to do here.
> For PipeWire/PulseAudio, the pipewire-pulseaudio and pulseaudio
> packages had the following stanzas added:
>
> Provides: pulseaudio-daemon
> Conflicts: pulseaudio-daemon
>
> For pipewire-media-session/wireplumber, those packages had the
> following stanzas added:
>
> Provides: pipewire-session-manager
> Conflicts: pipewire-session-manager
>
> The Provides+Conflicts on a single virtual name makes it so RPM knows
> that those packages are equivalent providers, but only one of them can
> be present on a system at a time. Attempting to install the other
> would trigger a Conflicts, and you'd need to use "dnf swap" to switch
> implementations.
>
> For your case, each Keylime agent package would have the following stanzas:
>
> Provides: keylime-tpm-agent
> Conflicts: keylime-tpm-agent
>
> Those two stanzas tell RPM that keylime-agent-python and
> keylime-agent-rust are equivalent, but conflicting providers of
> "keylime-tpm-agent" and will only allow one or the other.

Thanks for the help here, and I will update the proposal to reflect
your suggestion.

Best Regards,
Sergio