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

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.