On Fri, Nov 21, 2025 at 8:38 PM Peter Krempa <[email protected]> wrote:
> On Fri, Nov 21, 2025 at 20:20:56 +0530, Arun Menon wrote: > > 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. > > [...] > > > 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? > > You can encode which cipher was used in the suffix of the filename e.g: > > SECRETNAME.aes256, SECRETNAME.base64 > > If we ever switch to another cipher we'll use a different suffix. > > And when loading them look at the most recently used cipher/format > first, and go back the list. > > You then can either remember which ciplher one was used internally, so > that we use the same on output, or we'll unconditionally write out in > the newest format possible. In the latter case you must ensure that the > older format file was wiped once the value is written out. > I see. I was only afraid of the scenario where we migrate from an older version of libvirt to the new one and the encryption scheme changes in between. A secret on the disk which was encrypted with scheme A will not be loaded automatically, because the new scheme will not be able to decrypt it.
