From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVfO1-0008TR-MS for qemu-devel@nongnu.org; Wed, 11 Mar 2015 08:05:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVfO0-0004VG-NV for qemu-devel@nongnu.org; Wed, 11 Mar 2015 08:05:17 -0400 From: Markus Armbruster References: <1426008400-22016-1-git-send-email-armbru@redhat.com> <20150310181337.GG14255@redhat.com> <87pp8frk0b.fsf@blackfin.pond.sub.org> <20150311095926.GC22609@redhat.com> Date: Wed, 11 Mar 2015 13:05:08 +0100 In-Reply-To: <20150311095926.GC22609@redhat.com> (Daniel P. Berrange's message of "Wed, 11 Mar 2015 09:59:26 +0000") Message-ID: <871tkvn3ij.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH RFC 0/2] Limit support for encrypted images to qemu-img List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: kwolf@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, stefanha@redhat.com, kraxel@redhat.com "Daniel P. Berrange" writes: > On Wed, Mar 11, 2015 at 09:55:16AM +0100, Markus Armbruster wrote: >> "Daniel P. Berrange" 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. [...]