On Tue, Jun 21, 2016 at 10:01:50 -0400, John Ferlan wrote:
>
>
> On 06/21/2016 08:20 AM, Peter Krempa wrote:
> > On Mon, Jun 13, 2016 at 20:27:51 -0400, John Ferlan wrote:
> >> Currently the assumption is there is one type of disk encryption - in
> >> some qcow format which is old and crusty... But there's a new sheriff
> >> in town known as 'luks' and we'll need to handle that shortly
> >>
> >> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
> >> ---
> >> src/util/virstoragefile.c | 54 ++++++++++++++++++++++++++++-------------------
> >> 1 file changed, 32 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
> >> index 6d7e5d9..5c2519c 100644
> >> --- a/src/util/virstoragefile.c
> >> +++ b/src/util/virstoragefile.c
> >
> > [...]
> >
> >> @@ -111,6 +111,11 @@ enum {
> >> BACKING_STORE_ERROR,
> >> };
> >>
> >> +enum fi_crypt {
> >> + FI_CRYPT_NONE = 0,
> >> + FI_CRYPT_QCOW
> >
> > This lacks the "VIR_" prefix. Also I don't really see a point in adding
> > this. Currently it's used to distinguish between an encrypted QCOW and
> > an unencrypted QCOW. With LUKS (as you note later in a comment) it's
> > implied that they are encrypted and thus we don't need a side band to
> > store the same data.
> >
>
> OK I can drop this... It would be replaced in "a" subsequent patch with
> a more direct "meta->format == VIR_STORAGE_FILE_LUKS" type check in
> order to allocate meta->encryption
I concluded that it might be desired to keep this as long as you want to
parse more data from the LUKS header. The name change is desired though.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list