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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




>>> Ok, so for LUKS i'd expect us to continue to just use the existing
>>> USAGE_TYPE_VOLUME we already have for this purpose.
>>>
>>
>> That then requires the "usage" of a <secret> in the domain xml to list
>> the volume path. So rather than:
>>
>>       <encryption format='luks'>
>>          <secret type='passphrase' usage='luks_example'/>
>>       </encryption>
>>
>> it'd be:
>>
>>       <encryption format='luks'>
>>          <secret type='volume' usage='$LUKS_VOLUME_PATH'/>
>>       </encryption>
>>
>> (or of course uuid='$UUID')
>>
>> I was looking to have a "more clear" delineation between a secret that
>> "could be" generated automagically (e.g. some randomly generated
>> passphrase) for a qcow volume and one that "someone" defines/sets for a
>> luks volume.
> 
> Why would we want any such delineation ? Regardless of where the secret
> is generated, it is still used in the same functional manner, so I don't
> see an obvious benefit to distinguish them ?
> 

One is generated for you (essentially) and one is provided by someone in
order to unlock their luks volume.  I guess I see a functional
delineation between the two, although I do understand what your
viewpoint is on this. There may have been another reason I felt the need
to delineate, but that would mean more time to put the qcow volume
encryption code back into my head than I have to process right now...

John

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]