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? John