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

[Daniel P. Berrange]

On Tue, Jul 05, 2016 at 10:16:10AM -0400, John Ferlan wrote:
> 
> 
> On 07/05/2016 09:37 AM, Daniel P. Berrange wrote:
> > On Tue, Jul 05, 2016 at 09:33:30AM -0400, John Ferlan wrote:
> >>
> >>
> >> On 07/04/2016 09:42 AM, Daniel P. Berrange wrote:
> >>> On Fri, Jun 24, 2016 at 04:53:31PM -0400, John Ferlan wrote:
> >>>> Add a new secret type known as "passphrase" - it will handle adding the
> >>>> secret objects that need a passphrase without a specific username.
> >>>>
> >>>> The format is:
> >>>>
> >>>>    <secret ...>
> >>>>      <uuid>...</uuid>
> >>>>      ...
> >>>>      <usage type='passphrase'>
> >>>>        <name>mumblyfratz</name>
> >>>>      </usage>
> >>>>    </secret>
> >>>
> >>> I'm not seeing the purpose of adding this secret usage type. It also
> >>> seems quite different from the usage types we have already.
> >>>
> >>> The essential purpose of the usage 'name' is to allow you to figure
> >>> out what corresponding libvirt object is using the secret. So for
> >>> example with usage type=volume, the name refers to the disk path
> >>> of the volume. With usage type=iscsi or type=ceph, the name refers
> >>> to the server name.
> >>>
> >>> This usage type=passphrase is not directly associating the secret
> >>> with anything, and doesn't appear to have any defined sematics for
> >>> what the 'name' should contain or refer to.
> >>>
> >>> This all feels quite odd & possibly wrong to me.
> >>>
> >>
> >> FWIW: I'm on PTO this week, but I do have a few minutes of time to
> >> provide some feedback...
> > 
> > NP, we can wait until you return to resolve it - as long as we decide
> > before the 2.1 release we're fine.
> > 
> > 
> >> This type of secret started out in my own branches as a "luks" secret,
> >> since that's what it was designed to (at least) initially support.
> >>
> >> After starting to think and work with the TLS code, I modified it to a
> >> "key" secret - mainly because they were the essentially the same type of
> >> secret. At that time I did consider passphrase, but wasn't convinced it
> >> was the best name, so "key" was it (plus less characters to type). I
> >> also figured it was better to use the same type of secret since they
> >> provided essentially the same functionality - a key/passphrase to be
> >> provided for some other object to unlock access to the object (for lack
> >> of a better term, at this moment).
> >>
> >> Both series were posted and I noted the common parts of both. The luks
> >> code was reviewed and the suggestion was to use "passphrase", so I went
> >> that way.
> > 
> > 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 ?

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 :|