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

[Markus Armbruster <armbru@redhat.com>]

"Daniel P. Berrange" <berrange@redhat.com> writes:

> On Wed, Mar 11, 2015 at 09:55:16AM +0100, Markus Armbruster wrote:
>> "Daniel P. Berrange" <berrange@redhat.com> writes:
[...]
>> > My only concern here is whether we've given users enough prior
>> > warning. While we added that doc change a year ago, what are the
>> > odds that anyone has actually read those docs & noticed the warning.
>> > Should we have one major release where we log a deprecation warning
>> > on stderr, informing users of an explicit timeframe for its removal,
>> > before we actually use the big hammer of disabling it permanently ?
>> 
>> I'm fine with that.  In fact, I could agree to pretty much any
>> deprecation schedule, as long as we start it *now*.
>
> IIUC, the 2.3.0 major branch is targetted for end of this month,
> so we could put in code that issues a deprecation warning on
> stderr for 2.3.0, and then delete all this stuff when GIT master
> opens for 2.4.0 development ?

Let's do that.  Kevin, any objections?

>> > 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. 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.

Makes sense.

>                                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.

The obvious command line use should prompt for the key.

A reasonably safe non-interactive way to start with an encrypted image
would be nice, but I haven't considered details.

[...]