qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/9] encryption code changes


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 0/9] encryption code changes
Date: Wed, 18 Feb 2009 20:57:14 -0300
User-agent: Sup/git

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 via email to

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