----- "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:
> For the domain XML I agree that libirt would not need to worry about
> multiple LUKS keys, but for the storage volume XML we would need to
> expose the fact that there are multiple keys,or allow creation of
> volumes with multiple keys.
I don't know. Does a fact that a feature exist imply that libvirt must fully expose it? Any use case for multiple LUKS passphrases I can think of is a bit far-fetched.
> > We know that the type and amount of information that will need to be
> > stored will vary depending on the "encryption format"; on the other
> > hand, expecting that the information consists of independent "secrets",
> > each with a simple and format-independent definition, is probably too
> > optimistic. (As mentioned above, we might need a key slot ID associated
> > with a LUKS passphrase; we might also need a password hash algorithm
> > associated with a dm-crypt passphrase. The encryption formats used in
> > practice are often complex enough that a "simple passphrase" can not
> > be used.) Once we have to assume that each secret can have an "encryption
> > format"-dependent format, I think it is much clearer to use something like
>
> The idea of a 'key slot' and 'password hash algorithm' are not neccessarily
> unique to LUKS though.
No, but the specific semantics and value ranges are very likely to be different across formats.
> If we get 2 different encryption formats both requiring
> the concept of a 'key slot' we need to represent them in the same way in the
> XML, not hve a different XML for each format.
I was arguing about making the internal representation format-specific, not the XML.
In the XML, having something like <secret type='...' id='...'> and <parameter name='...' id='...'> is quite reasonable.
I think this is not the case in the internal representation - the information will eventually have to be "parsed" into format-specific variables, and it seems better to me to do this at once from the XML, than to create an additional internal representation and additionl "parsing" code.
<snip>
> The libvirt approach to XML representation is to try and define XML format
> that are indenpedant of specific implementations. This does imply that the
> XML parser cannot really do anything beyond basic syntactic validation,
> near zero semantic validation. The task of semantic validation of the
> parsed data, is thus passed off to the internal drivers which provide the
> specific implementations.
Not having any driver-specific knowledge in the generic parser does make sense; I'll change the code.
Mirek
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list