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

[Daniel P. Berrange]

On Tue, Jul 05, 2016 at 10:44:30AM -0400, John Ferlan wrote:
> 
> 
> >>> 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
no functional difference. The usage type is associating with the consuming
so I think the difference in generation approach is really irrelevant for
the consumer.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|