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

John Ferlan jferlan at redhat.com
Tue Jul 5 13:33:30 UTC 2016



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




More information about the libvir-list mailing list