* at run time, if the fsverity rpm plugin is enabled, rpm will
the fsverity signature key and enable fsverity on files that are
This requires CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y. Currently our
kernels are built without that. It seems like a simple addition (the
amount of code guarded by this is very small), but this should be added
to the Scope.
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;
There was already some chatter about signatures and verification in
the thread, but I didn't see a definite answer, and I think this is the
part that is currently the most underspecified.
In Fedora, we use a new package signing key for each Fedora release.
What key would be used for the fs-verity signatures: the same key,
a separate key? Edit: I see that the Change page says a dedicated key is used.
OK, so is this key rotated one per release or some different schedule?
How would the public part of the key be delivered to users?
How does one actually enable signature verification? Let's say I have
a kernel with CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y and rpm-plugin-fsverity
installed, and I installed some rpms, and the files from those rpms now
have now had the FS_IOC_ENABLE_VERITY ioctl done.
IIUC, I need to do some steps at each boot:
1. add all the keys to the keyring
2. set sysctl fs.verity.require_signatures=1
So… in 1., do I always load all the keys that Fedora has used for this
purpose, in case there are still some files on disk? Or is there some
mechanism to say that e.g. keys older than F(N-2) are now not necessary?
Who does 2.?
I think it'd be hard to enable this during a system upgrade: one would need
to reinstall all rpms (with new rpms carrying the fsverity metadata)
or some files become unreadable once 2. is done. This brings a question:
is there some rpm virtual Provides/Requires to specify that the fs-verity
stuff is present? I assume the user would want to triple-check that they
don't have any rpms without the metadata before enabling verification.
P.S. Those questions are about the mechanism, not policy or the threat model.
I have some questions about that, but I'll ask separately, since this mail
is lengthy already.