On Thu, Nov 27, 2025 at 12:52:27 +0530, Arun Menon via Devel wrote: > Libvirt secrets are stored unencrypted on the disk. > With this series we want to start encrypting the secrets. > > 1. Introduce the GnuTLS decryption wrapper functions that > work exact opposite to the encryption wrappers. > > 2. Add a new service called virt-secrets-init-encryption, that is > linked to the virtsecretd service. virtsecretd service only starts > after the new service generates a random encryption key. > > 3. Add a new secrets.conf configuration file that helps user to set > a. secrets_encryption_key - allows the user to specify the encryption > key file path, in case the default key is not to be used. > b. encrypt_data - set to 0 or 1. If set to 1, then the newly > added secrets will be encrypted. > > 4. Add encryption scheme or cipher attribute that will allow us to > choose the last used cipher. > > 5. Once we have the encryption key, and a reliable way to tell the daemon > what encryption scheme the secret object is using, we can encrypt the > secrets on disk and store them in <uuid>.<encryption_scheme> format. > It is important to note that if the encryption key is changed between > restarts, then the respective secret will not be loaded by the driver. > > This is a sincere attempt to improve upon the already submitted patch > https://lists.libvirt.org/archives/list/[email protected]/thread/KE6GVZQ45JTYFTE54CT7DMONSO2W3ZPV/ > > Resolves: https://issues.redhat.com/browse/RHEL-7125
Any reason this is labelled as RFC? I don't think there are any design problems preventing his from being merged.
