From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL7iE-0006tf-Ht for qemu-devel@nongnu.org; Wed, 05 Mar 2014 04:02:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WL7i8-0006R7-Ia for qemu-devel@nongnu.org; Wed, 05 Mar 2014 04:02:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:23006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL7i8-0006R2-8n for qemu-devel@nongnu.org; Wed, 05 Mar 2014 04:01:56 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2591sXa020165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 Mar 2014 04:01:54 -0500 Message-ID: <5316E800.80909@redhat.com> Date: Wed, 05 Mar 2014 10:01:52 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <87wqgflzno.fsf@blackfin.pond.sub.org> <531108CA.1060002@redhat.com> <5311F251.1030904@redhat.com> <87ob1l834u.fsf@blackfin.pond.sub.org> In-Reply-To: <87ob1l834u.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] The unholy encrypted image key mess List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi , Gerd Hoffmann Il 05/03/2014 09:24, Markus Armbruster ha scritto: > Paolo Bonzini 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? Possibly: diff --git a/block.c b/block.c index 38bbdf3..794946c 100644 --- a/block.c +++ b/block.c @@ -1384,6 +1384,12 @@ done: } QDECREF(options); + 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. Paolo