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@redhat.com> --- 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.