Hi, > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like being at proof-of-concept state. mkosi going fetch stuff from the internet to generate the initrd is clearly a non-starter (maybe not that much of a problem when doing it in koji where the next fedora repo is only one network hop away). I don't think mkosi is a hard requirement for unified kernel images though. Once the local configuration issues are solved it should be possible to run "dracut --no-hostonly" in koji + ship results instead of doing it on the installed host, no? > An alternative is to use the systemd credential logic for this (this > stuff: https://systemd.io/CREDENTIALS/). It allows encrypting and > signing small blobs of info (so called "credentials") with the local > TPM. They can then safely be stored on an untrusted medium (such as a > ESP/boot partition), and are verified/decrypted on access. The > "systemd-stub" EFI stub can automatically pick up such encrypted > credentials from the ESP too, similar to the extension initrd images > mentioned earlier in this thread. ("man systemd-stub" has details on the efi stub btw). > The credentials logic can also be used to for example pass a root pw > for the initrd in a safe way. Does systemd-cryptenroll use this? When getting the credentials for the encrypted root filesystem (or something else) from somewhere else, i.e. some attestation server such as https://keylime.dev/, how could that be integrated with systemd-creds best? Simply have the agent write to /run/credentials? > My expectation would be that by default we'd just use the GPT auto > discovery stuff and for "pet" systems maybe also encode the root > device with a credntial, but for "cattle" systems not bother. Yep. Is there some fallback mechanism btw? Most cloud images have just four partitions: bios-boot, efi esp, boot and root. And the root filesystem is simply the largest partition ... take care, Gerd _______________________________________________ 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
