On Fri, 21 Nov, 2025, 3:22 pm Daniel P. Berrangé, <[email protected]> wrote:
> 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 :| > Do you mean that we should not be using encryption scheme at all. While loading the secrets, all we need to do is check the file name suffix and if it is not ".base64", then enter the decryption logic? Regards, Arun Menon he/him Software Engineer, Virtualization Red Hat APAC
