qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@raisama.net>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 0/9] encryption code changes
Date: Wed, 18 Feb 2009 20:57:14 -0300	[thread overview]
Message-ID: <1235000328-sup-1863@blackpad> (raw)
In-Reply-To: <4997446A.10504@codemonkey.ws>


Oops. I've seen this message only today because I was not copied.
Comments below.

Excerpts from Anthony Liguori's message of Sáb Fev 14 20:23:38 -0200 2009:
> Eduardo Habkost wrote:
> > Hi,
> >
> > This patch series for qemu contain multiple changes on the way encryption
> > and authentication code is handled.
> >
> > The first patch is a behaviour change to avoid silent security holes on
> > the VNC server caused by user configuration errors.
> >
> > Patches 2 and 3 are bugfixes to some of the multiple problems
> > I had with monitor_readline(), when testing the qcow encryption
> > support. monitor_readline() is still not completely functional, but
> > at least it allows the qcow password to be read when an qcow encrypted
> > image is specified on the command-line, now.
> >   
> 
> Can you split these out?  Jan's monitor series may fix some of these too.

Yes, that part can be simply dropped. I've touched that code just because
I needed it to test the qcow encryption changes.

> 
> > The remaining patches may be more controversial. The first half makes the
> > use of aes.c and d3des.c optional at compile time. The rest remove aes.c
> > and d3des.c from the source tree and replace them with calls to libgcrypt.
> >   
> 
> I'm having a hard time justifying this.  We're adding an external 
> dependency but not gaining any features and potentially making existing 
> features unavailable on platforms that lack said dependency.  It's going 
> to create confusion and surprise.
> 
> I understand using gcrypt allows us to rely on a third party for 
> security/bug fixes but I'm having a hard time seeing the value of that 
> justify the pain this is going to cause a certain class of users.  I'm 
> open to persuasion but that's how I'm currently leaning.

In addition to the benefits of not duplicating code, another motivation
for the change is that in some countries the cryptography code can cause
additional bureaucracy when redistributing the software.

And, as Daniel Berrange noted, we already optionally link against gnutls,
that uses libgcrypto. I think it is reasonable to require it for the
qcow AES encryption support. Requiring it for VNC password authentication
may be more controversial, as it is a more commonly used feature.
-- 
Eduardo

      reply	other threads:[~2009-02-18 23:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-06 21:08 [Qemu-devel] [PATCH 0/9] encryption code changes Eduardo Habkost
2009-02-06 21:08 ` [Qemu-devel] [PATCH 1/9] vnc: abort on unknown options Eduardo Habkost
2009-02-06 21:08 ` [Qemu-devel] [PATCH 2/9] drive_init: Don't try to read passwords before monitor setup Eduardo Habkost
2009-02-06 21:08 ` [Qemu-devel] [PATCH 3/9] monitor_readline: poll pending bottom halves before readline_start() Eduardo Habkost
2009-02-06 21:08 ` [Qemu-devel] [PATCH 4/9] qcow: define QCOW_CRYPT_MAX Eduardo Habkost
2009-02-06 21:08 ` [Qemu-devel] [PATCH 5/9] qcow: make encryption support optional Eduardo Habkost
2009-02-06 21:08 ` [Qemu-devel] [PATCH 6/9] vnc: make DES-challenge authentication (aka "VNC auth") optional Eduardo Habkost
2009-02-06 21:08 ` [Qemu-devel] [PATCH 7/9] configure: add check for libgcrypt Eduardo Habkost
2009-02-06 21:08 ` [Qemu-devel] [PATCH 8/9] qcow: use libgcrypt AES implementation Eduardo Habkost
2009-02-06 21:09 ` [Qemu-devel] [PATCH 9/9] vnc: use libgcrypt for DES-challenge authentication Eduardo Habkost
2009-02-06 21:57 ` [Qemu-devel] Re: [PATCH 0/9] encryption code changes Jan Kiszka
2009-02-06 23:43 ` [Qemu-devel] " Anthony Liguori
2009-02-07 11:06   ` Daniel P. Berrange
2009-02-09 20:57   ` Eduardo Habkost
2009-02-07 11:00 ` Daniel P. Berrange
2009-02-14 22:23 ` Anthony Liguori
2009-02-18 23:57   ` Eduardo Habkost [this message]

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=1235000328-sup-1863@blackpad \
    --to=ehabkost@raisama.net \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    /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).