[Libguestfs] [PATCH 2/2] options: Allow multiple --key parameters and default keys.

[Richard W.M. Jones]

On Fri, Nov 15, 2019 at 03:23:02PM +0100, Pino Toscano wrote:
> On Tuesday, 12 November 2019 19:35:12 CET Richard W.M. Jones wrote:
> > This allows multiple --key parameters on the command line to match a
> > single device.  This could either be specified as:
> > 
> >   tool --key /dev/sda1:key:trykey1 --key /dev/sda1:key:trykey2
> > 
> > which would try "trykey1" and "trykey2" against /dev/sda1.
> 
> This seems OK for me, so you can attempt multiple keys for a device.
> 
> > And/or you can specify default keys which are tried against each
> > device (after more specific keys fail), eg:
> > 
> >   tool --key :key:defaultkey1 --key :key:defaultkey2
> > 
> > which would try "defaultkey1" and "defaultkey2" against all devices.
> 
> However I do not see the point in this: IMHO you better make it explicit
> which key is used for a certain device.

It's considerably more convenient for callers if they don't have to
store this mapping between opaque libguestfs device names (a concept
which is meaningless to most users and to the software which
orchestrates virt-v2v at scale), and keys.

Also there's no actual penalty to making this feature available, it's
a natural extension which falls out from the implementation, and it
doesn't affect performance unless the caller adds multiple --key
parameters.  It's also how LUKS itself works if you enable
decrypt_keyctl in crypttab.

> Also, this makes it possible so
> in case of two similar guests like:
> - /dev/sda1 with key "key1", and /dev/sda2 with key "key2"
> - /dev/sda1 with key "key2", and /dev/sda2 with key "key1"
> the above command like will work in the same way, with no indication of
> which key was successfully used for which device -- so you can silently
> swap the first guest for the second with no changes to the v2v command
> line...

I didn't understand this.  It seems an unlikely scenario in the first
place, and has no ill effects even if it does occur.

> What's the use case for this?

So that IMS doesn't have to collect an exact mapping between opaque
libguestfs device names and keys, which will require some user to have
to enter device names that they don't understand into a UI without any
making typos rather than just supplying a list of keys that apply to a
single guest.

> Please split this patch in two:
> - multiple keys for the same device
> - keys for all devices

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org