[Top][All Lists]

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

Re: [Qemu-devel] The unholy encrypted image key mess

From: Paolo Bonzini
Subject: Re: [Qemu-devel] The unholy encrypted image key mess
Date: Wed, 05 Mar 2014 10:01:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Il 05/03/2014 09:24, Markus Armbruster ha scritto:
Paolo Bonzini <address@hidden> writes:

Il 28/02/2014 23:08, Eric Blake ha scritto:
Use the fact that we are calling the next release "2.0" to actually kill
qemu disk encryption as a horribly botched feature, on the grounds that
we are doing users a favor by not letting them use broken encryption?

Only for qemu, of course---qemu-img would still have support for
encryption, and there's no reason to risk stability by removing all
the monitor code right now.

Right now = for 2.0?


diff --git a/block.c b/block.c
index 38bbdf3..794946c 100644
--- a/block.c
+++ b/block.c
@@ -1384,6 +1384,12 @@ done:

+    if (bdrv_key_required(bs) && use_bdrv_whitelist) {
+        ret = -EINVAL;
+        error_setg(errp, "Encrypted images are not supported by QEMU "
+                   "anymore.\nPlease use qemu-img to unencrypt them.");
+        goto close_nad_fail;
+    }
     if (!bdrv_key_required(bs)) {
         bdrv_dev_change_media_cb(bs, true);

I'm not trying to push anything into 2.0.  I'm trying to clean up
another mess (qerror, to be precise), and the encrypted images mess is
in my way.  I don't expect to complete the qerror job in time for 2.0.

What are you cleaning up exactly?

However, wouldn't we have the same problems even with a sane encrypted
image format (based on LUKS, for example)?

Yes, and when we get that, we'll shoehorn it into the same idiotic user
interface we have now :)

Let's just open bugs (oh if only Launchpad supported tracker bugs) for now.

Filing bugs won't help me with cleaning up qerror.  If preserving the
current idiotic encrypted image interfaces is required, I'll have no
choice but pour in the necessary work.  Sure wish I could use the time
for something more immediately useful than preserving an idiotic
interface to a feature we don't want anybody to use.

I'm not sure why it helps to kill an idiotic user interface, if we (a) have plans to reimplement the same feature in the future (b) don't have any ideas on how to have a non-idiotic user interface for the same feature.

Fixing it, at least partly---that helps. But killing it doesn't help, unless we drop all plans to have sane image encryption.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]