Re: [libvirt] [PATCH v3 02/10] conf: Add new secret type "passphrase"

>>> Ok, so for LUKS i'd expect us to continue to just use the existing >>> USAGE_TYPE_VOLUME we already have for this purpose. >>> >> >> That then requires the "usage" of a <secret> in the domain xml to list >> the volume path. So rather than: >> >> <encryption format='luks'> >> <secret type='passphrase' usage='luks_example'/> >> </encryption> >> >> it'd be: >> >> <encryption format='luks'> >> <secret type='volume' usage='$LUKS_VOLUME_PATH'/> >> </encryption> >> >> (or of course uuid='$UUID') >> >> I was looking to have a "more clear" delineation between a secret that >> "could be" generated automagically (e.g. some randomly generated >> passphrase) for a qcow volume and one that "someone" defines/sets for a >> luks volume. > > Why would we want any such delineation ? Regardless of where the secret > is generated, it is still used in the same functional manner, so I don't > see an obvious benefit to distinguish them ? > One is generated for you (essentially) and one is provided by someone in order to unlock their luks volume. I guess I see a functional delineation between the two, although I do understand what your viewpoint is on this. There may have been another reason I felt the need to delineate, but that would mean more time to put the qcow volume encryption code back into my head than I have to process right now...

From the POV of the code that is consuming the secrets, there absolutely