"Daniel P. Berrange" <berra...@redhat.com> writes: > On Wed, Mar 11, 2015 at 09:55:16AM +0100, Markus Armbruster wrote: >> "Daniel P. Berrange" <berra...@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. [...]
