** 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.