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

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.

> 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? The secret usage is associated with a particular type of object requiring credentials. In that case the object type is a TLS key. The fact that you can use the TLS key for different services is not relevant. So I'd say the usage would be USAGE_TYPE_TLS_KEY and the data associated with it would be the path of the TLS key pem file. Regards, Daniel