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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list