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