On Fri, Nov 21, 2025 at 08:08:20AM +0100, Peter Krempa via Devel wrote: > On Thu, Nov 20, 2025 at 22:23:45 +0530, Arun Menon via Devel wrote: > > A new attribute is required, to store the encryption scheme used while > > encrypting the secret. This value will be "none" if the secret is > > stored in base64 format. > > > > For backwards compatibility, the secret will not be encrypted when the > > attribute itself is absent in the configuration file. In other words, > > the secret will be stored on the disk in base64 encoded format. > > > > This new attribute is essential to be stored on the disk in the xml file, > > so that we can effectively decrypt the secrets while loading them. > > It also allows us to add more encryption schemes in the future. > > Storing it in the XML also gives the user the possibility to control the > encryption. Do we want that? The only reason I see for a user to > configure this field is to ensure that secrets are "downgraded" to an > older encryption scheme, but I'm not sure if that is actually useful. > > Shouldn't this remain an implementation detail and thus not exposed to > the user? In such case you could tell them apart e.g. using a filename > suffix.
Agreed, the file suffix is all we want - the backend impl choice should not be exposed to the end user XML. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
