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