From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] The unholy encrypted image key mess
Date: Wed, 05 Mar 2014 09:24:01 +0100 [thread overview]
Message-ID: <87ob1l834u.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <5311F251.1030904@redhat.com> (Paolo Bonzini's message of "Sat, 01 Mar 2014 15:44:33 +0100")
Paolo Bonzini <pbonzini@redhat.com> 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?
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.
> 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.
next prev parent reply other threads:[~2014-03-05 8:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 21:01 [Qemu-devel] The unholy encrypted image key mess Markus Armbruster
2014-02-28 22:08 ` Eric Blake
2014-03-01 14:44 ` Paolo Bonzini
2014-03-05 8:24 ` Markus Armbruster [this message]
2014-03-05 9:01 ` Paolo Bonzini
2014-03-05 9:49 ` Markus Armbruster
2014-03-05 8:15 ` Markus Armbruster
2014-03-05 9:29 ` Gerd Hoffmann
2014-03-05 10:16 ` Kevin Wolf
2014-03-05 12:45 ` Markus Armbruster
2014-03-03 10:58 ` Kevin Wolf
2014-03-05 8:43 ` Markus Armbruster
2014-03-05 9:17 ` Paolo Bonzini
2014-03-05 9:33 ` Andreas Färber
2014-03-05 10:36 ` Markus Armbruster
2014-03-05 10:40 ` Paolo Bonzini
2014-03-05 12:50 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ob1l834u.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.