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

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

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.

If it needs to change again, that can be done when I'm back next week (or by someone before I get back). If the two need to be separated that's fine too. They'll share a lot of similarities though. I think other than the target service object they support, the iscsi and ceph secret are fairly similar. So it's not unprecedented. If they are separated, then does that mean there's a TCPTLS secret, a MIGRATIONTLS secret, and an NBDTLS secret?