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:
> 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.
> * at run time, if the fsverity rpm plugin is enabled, rpm will
> the fsverity signature key and enable fsverity on files that are
Is this signature key the fedora rpm package signing key?
Or some seperate fsverity key?
fs-verity needs a RSA key/cert pair for file signing at package
signature time. At package install time, the cert needs to be loaded in
the appropriate kernel keyring. We've always used a dedicated keypair
during testing -- I'm not actually sure if the package signing key
could be reused for this, as it's a GPG key, but this is something we
should follow up on.
> fs-verity works by using a Merkle tree to generate a checksum
> every data block in the system, and reads will fail if a single
every data block? or every packaged in rpms data block?
fs-verity only operates on files where it has been enabled via its
ioctl (which, if you install the RPM plugin, is taken care of by RPM on
your behalf). For those, fs-verity will checksum every data block
whenever it's accessed and validate it still matches.
> block read fails it’s checksum. The signature of the the file
> validated against a public key loaded into the kernel keyring.
> fsverity operates on block reads, its runtime cost is small (as it
> only needs to verify the block that is being accessed), and it can
> protect from alterations at any point in time.
Is this via dm_verity kernel module? Or thats a completely seperate
It's somewhat inspired by dm-verity, but it's a separate
implementation, the only shared logic is the hash computation code in
> == Scope ==
> * Proposal owners
> ** btrfs kernel enablement work
> landed in 5.15]); see this
> blog post] for more details
What does this mean for all the other filesystems? They would just be
slower since btrfs is computing the trees as part of it's normal
fs-verity requires support in the underlying filesystem. If you're
using a filesystem that doesn't support it and attempt to enable fs-
verity on a file, the ioctl will fail. Note that this is only a concern
at runtime, not at build time.
> ** koji integration: koji will need to add the fs-verity
> packages when signing them
Well, koji doesn't sign packages. robosignatory listens for messages
the message bus for koji tagging and based on it's config, it asks
to sign rpms and import the signatures into koji.
There's support in robosignatory to ask to sign files (used for the
short lived IMA stuff), but I suspect it would need a new ability for
Finally who is going to write this? Change owners?
Or do you expect robosignatory maintainers to do so?
Thanks for clarifying! Yes, I think robosignatory is likely what we
want here. We (the Change owners) expect to do the work, though we'll
likely need some advice/help around code review, testing and
> * fs-verity requires filesystem support; currently support for
> and f2fs is already available; support for btrfs landed in 5.15
No xfs support?
Correct, XFS doesn't support fs-verity at the moment (though it could
be implemented if one wanted to).