Hello,
On Thu, Dec 02, 2021 at 07:10:32PM -0500, Josh Boyer wrote:
On Thu, Dec 2, 2021, 5:33 PM Davide Cavalca via devel <
devel(a)lists.fedoraproject.org> wrote:
> On Thu, 2021-12-02 at 13:09 -0800, Kevin Fenzi wrote:
> > On Thu, Dec 02, 2021 at 02:36:51PM -0500, Ben Cotton wrote:
> > ...snip...
> > >
> > > In the context of rpm, there are two parts to this:
> > > * at build time, we compute the Merkle tree for the files within a
> > > package, then sign it and ship it as part of the rpm metadata;
> >
> > This is some kind of seperate signing that happens at build time?
> >
> > Or it's added to the rpm metadata and covered by the normal package
> > signing if/when the package is signed?
>
> As part of the signing flow (e.g. via rpmsign), the Merkle tree is
> generated and a signature is computed from it, which is then added to
> the rpm metadata.
>
IMA received significant pushback on the impact to RPMs and signing
implications in Fedora. How does fs-verity compare here?
We wrote up a comparison
here:
https://fedoraproject.org/wiki/Changes/FsVerityRPM#Relationship_with_IMA
Alternatively/additionally, why is fs-verity worth the hit for Fedora
where
IMA was not.
The hit is much smaller; per
https://fedoraproject.org/wiki/Changes/FsVerityRPM#Merkle_tree_cost
- if the plugin is installed, the Merkle tree is stored but it's 1/127th
the original file size
- the RPM only ships the signature, not the tree itself; per
https://fedoraproject.org/wiki/Changes/FsVerityRPM#Signature_overhead_cost
in practice we see a minimal to no increase in the size of the RPM
So as proposed in this Change, users can opt in by installing the
plugin, otherwise they will be mostly unimpacted.
As discussed in the write-up - IMA does have a richer policy system, and
could potentially be integrated (so we use IMA but with a fsverity
backend) to get the best of both worlds.
Best regards,
--
Michel Alexandre Salim
profile:
https://keyoxide.org/michel@michel-slm.name