> * at run time, if the fsverity rpm plugin is enabled, rpm will install > the fsverity signature key and enable fsverity on files that are > installed. 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. Zbyszek 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
