On Fri, Nov 21, 2025 at 21:05:23 +0530, Arun Menon wrote: > 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]>
[...] > > > 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. Yes you definitely need to be able to tell which cipher/method was used on the actual on-disk file. But since we don't want to expose it the filename seems to be the most straightforward solution.
