qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC 0/2] Limit support for encrypted images to q


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH RFC 0/2] Limit support for encrypted images to qemu-img
Date: Wed, 11 Mar 2015 11:10:16 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 11.03.2015 um 10:59 hat Daniel P. Berrange geschrieben:
> On Wed, Mar 11, 2015 at 09:55:16AM +0100, Markus Armbruster wrote:
> > "Daniel P. Berrange" <address@hidden> writes:
> > > FWIW, I could see an improved interaction scheme working as follows
> > >
> > > First, introduce a new monitor command for setting named passwords,
> > >
> > >     add_key mykey1 SECRETDATA
> > >
> > > Now, extend the blockdev_add so that you can provide key names
> > > by adding
> > >
> > >     'keyname': 'mykey1'
> > >
> > > as a parameter in the json args.
> > 
> > Can you explain why that's better than sticking 'key': SECRETDATA right
> > into blockdev-add's arguments?
> 
> Just have a small preference to keep passwords separated from the
> rest of the data, so when logging the stuff for debug purposes we
> don't compromise people's passwords quite so readily.

Indeed, it would be very easy for a password to end up in error
messages, or in json: "filenames" that might be used in query-block
replies or in a backing file path. BDS options should be considered
more or less public.

> It is more
> straightforward for us to mask out the passwords if we can just
> match on the command name, and not have to try to grok the specific
> field in a large set of args.  Also in terms of cold startup, it
> is not desirable to have the password directly included in the
> args to -drive or equiv, as that's visible in process listings.

Right, that too.

Kevin



reply via email to

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