From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, stefanha@redhat.com, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] block: Deprecate QCOW/QCOW2 encryption
Date: Fri, 13 Mar 2015 14:22:57 -0600 [thread overview]
Message-ID: <55034721.6000202@redhat.com> (raw)
In-Reply-To: <1426277380-25665-1-git-send-email-armbru@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]
On 03/13/2015 02:09 PM, Markus Armbruster wrote:
> We've steered users away from QCOW/QCOW2 encryption for a while,
> because it's a flawed design (commit 136cd19 Describe flaws in
> qcow/qcow2 encryption in the docs).
>
> In addition to flawed crypto, we have comically bad usability, and
> plain old bugs. Let me show you.
>
> This stuff is worse than useless, it's a trap for users.
>
> If people become sufficiently interested in encrypted images to
> contribute a cryptographically sane implementation for QCOW2 (or
> whatever other format), then rewriting the necessary support around it
> from scratch will likely be easier and yield better results than
> fixing up the existing mess.
>
> Let's deprecate the mess now, drop it after a grace period, and move
> on.
>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
> block.c | 7 +++++++
> qemu-doc.texi | 11 ++++++-----
> tests/qemu-iotests/049.out | 6 ++++++
> tests/qemu-iotests/087.out | 18 ++++++++++++++++++
> 4 files changed, 37 insertions(+), 5 deletions(-)
Worth having in 2.3.
Reviewed-by: Eric Blake <eblake@redhat.com>
> +++ b/qemu-doc.texi
> @@ -539,8 +539,8 @@ storage.
> @item qcow2
> QEMU image format, the most versatile format. Use it to have smaller
> images (useful if your filesystem does not supports holes, for example
> -on Windows), optional AES encryption, zlib based compression and
> -support of multiple VM snapshots.
> +on Windows), zlib based compression and support of multiple VM
> +snapshots.
[Side note - Windows NTFS supports holes (so the claim that Windows
doesn't support holes is false, although it is true for other typical
Windows filesystems such as FAT). On the other hand, Windows hole
support is so bad that it typically causes worse performance (at one
point, Cygwin used NTFS holes wherever possible, but now defaults to no
holes unless you explicitly modify mount options to request Cygwin to
use them, because of the performance improvement). Doesn't affect this
patch, though.]
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2015-03-13 20:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 20:09 [Qemu-devel] [PATCH] block: Deprecate QCOW/QCOW2 encryption Markus Armbruster
2015-03-13 20:21 ` Markus Armbruster
2015-03-13 20:22 ` Eric Blake [this message]
2015-03-16 10:27 ` Daniel P. Berrange
2015-03-16 12:09 ` Kevin Wolf
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=55034721.6000202@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).