Hi! ** are you using 'journal --setup-keys' and 'journalctl --verify-key=…'? In no, feel free to ignore this. ** background story: [A very simplified explanation of "Forward Secure Sealing": public-private key pair is generated when setting up a journal, the private key is copied off the device and stored somewhere, usually using a QR code and a phone, and when the journal is being rotated the key stored on the device is propagated in one-way fashion, so that new private keys can be generated from the older ones, but not vice versa. If somebody tried to generate a fake journal for past history, that would not pass verification. But it is possible to just delete older journal from the device, so FSS should prevent unnoticed modification, but probably not deletion of logs.] The code for FSS is old and clunky, and is the only thing that requires libgcrypt in libsystemd.so and the systemd package itself. It's not widely used, and I'm considering two options: 1. make that code a plugin a that is loaded if available. It could be packaged as a subpackage, so only users who use it would get libgcrypt. 2. just disable support for this in the Fedora package. Hence the question in $subject… If nobody is using it, 2. would be the easier option. Option 1. gives more flexiblity to users, but it isn't so easy to create a "clean cut" and making this into a plugin would require quite a bit of work, and I'm not sure if it's worth the trouble to develop and maintain this. FSS is implemented using libgcrypt's bignums. The code doesn't really have tests and it's not clear how robust the verification is against hostile data. Systemd has moved (almost completely with F36) from using multiple crypto libraries to relying almost exclusively on openssl. The code for FSS is the only thing that requires libgcrypt in a normal systemd installation. It is also the only thing that requires a crypto library in libsystemd.so, so it effectively pulls in libgcrypt into anything that links to libsystemd.so, which is many things. So option 2. gives us a nice reduction in code size and exposure. Zbyszek _______________________________________________ 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
