[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH RFC 0/2] Limit support for encrypte
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH RFC 0/2] Limit support for encrypted images to qemu-img |
Date: |
Wed, 11 Mar 2015 13:05:08 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
"Daniel P. Berrange" <address@hidden> writes:
> On Wed, Mar 11, 2015 at 09:55:16AM +0100, Markus Armbruster wrote:
>> "Daniel P. Berrange" <address@hidden> 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.
[...]
- Re: [Qemu-block] [Qemu-devel] [PATCH RFC 1/2] block: Limit opening of encrypted images to qemu-img, (continued)
Re: [Qemu-block] [Qemu-devel] [PATCH RFC 0/2] Limit support for encrypted images to qemu-img, Daniel P. Berrange, 2015/03/10
Re: [Qemu-block] [PATCH RFC 0/2] Limit support for encrypted images to qemu-img, Paolo Bonzini, 2015/03/12