On Thu, Jan 30, 2020 at 01:38:47PM +0100, Kevin Wolf wrote:
> Am 28.01.2020 um 18:32 hat Daniel P. Berrangé geschrieben:
> > On Tue, Jan 28, 2020 at 05:11:16PM +0000, Daniel P. Berrangé wrote:
> > > On Tue, Jan 21, 2020 at 03:13:01PM +0200, Maxim Levitsky wrote:
> > > > On Tue, 2020-01-21 at 08:54 +0100, Markus Armbruster wrote:
> > > >
> > > > <trimmed>
> > > >
> > > > > > +##
> > > > > > +# @LUKSKeyslotUpdate:
> > > > > > +#
> > > > > > +# @keyslot: If specified, will update only keyslot with
> > > > > > this index
> > > > > > +#
> > > > > > +# @old-secret: If specified, will only update keyslots that
> > > > > > +# can be opened with password which is contained
> > > > > > in
> > > > > > +# QCryptoSecret with @old-secret ID
> > > > > > +#
> > > > > > +# If neither @keyslot nor @old-secret is
> > > > > > specified,
> > > > > > +# first empty keyslot is selected for the update
> > > > > > +#
> > > > > > +# @new-secret: The ID of a QCryptoSecret object providing a
> > > > > > new decryption
> > > > > > +# key to place in all matching keyslots.
> > > > > > +# null/empty string erases all matching keyslots
> > > > >
> > > > > I hate making the empty string do something completely different than
> > > > > a
> > > > > non-empty string.
> > > > >
> > > > > What about making @new-secret optional, and have absent @new-secret
> > > > > erase?
> > > >
> > > > I don't remember already why I and Keven Wolf decided to do this this
> > > > way, but I think that you are right here.
> > > > I don't mind personally to do this this way.
> > > > empty string though is my addition, since its not possible to pass null
> > > > on command line.
> > >
> > > IIUC this a result of using "StrOrNull" for this one field...
> > >
> > >
> > > > > > +# Since: 5.0
> > > > > > +##
> > > > > > +{ 'struct': 'LUKSKeyslotUpdate',
> > > > > > + 'data': {
> > > > > > + '*keyslot': 'int',
> > > > > > + '*old-secret': 'str',
> > > > > > + 'new-secret' : 'StrOrNull',
> > > > > > + '*iter-time' : 'int' } }
> > >
> > > It looks wierd here to be special casing "new-secret" to "StrOrNull"
> > > instead of just marking it as an optional string field
> > >
> > > "*new-secret": "str"
> > >
> > > which would be possible to use from the command line, as you simply
> > > omit the field.
> > >
> > > I guess the main danger here is that we're using this as a trigger
> > > to erase keyslots. So simply omitting "new-secret" can result
> > > in damage to the volume by accident which is not an attractive
> > > mode.
>
> Right. It's been a while since I discussed this with Maxim, but I think
> this was the motivation for me to suggest an explicit null value.
>
> As long as we don't support passing null from the command line, I see
> the problem with it, though. Empty string (which I think we didn't
> discuss before) looks like a reasonable enough workaround to me, but if
> you think this is too much magic, then maybe not.
>
> > Thinking about this again, I really believe we ought to be moire
> > explicit about disabling the keyslot by having the "active" field.
> > eg
> >
> > { 'struct': 'LUKSKeyslotUpdate',
> > 'data': {
> > 'active': 'bool',
> > '*keyslot': 'int',
> > '*old-secret': 'str',
> > '*new-secret' : 'str',
> > '*iter-time' : 'int' } }
> >
> > "new-secret" is thus only needed when "active" == true.
>
> Hm. At the very least, I would make 'active' optional and default to
> true, so that for adding or updating you must only specify 'new-secret'
> and for deleting only 'active'.
Is that asymmetry really worth while ? It merely saves a few
characters of typing by omitting "active: true", so I'm not
really convinced.
>
> > This avoids the problem with being unable to specify a null for
> > StrOrNull on the command line too.
>
> If we ever get a way to pass null on the command line, how would we
> think about a struct like this? Will it still feel right, or will it
> feel like we feel about simple unions today (they exist, we would like
> to get rid of them, but we can't because compatibility)?
Personally I really don't like the idea of using "new-secret:null"
as a way to request deletion of a keyslot. That's too magical
for an action that is so dangerous to data IMhO.
I think of these operations as activating & deactivating keyslots,
hence my suggestion to use an explicit "active: true|false" to
associate the core action being performed, instead of inferring
the action indirectly from the secret.
I think this could lend itself better to future extensions too.
eg currently we're just activating or deactivating a keyslot.
it is conceivable in future (LUKS2) we might want to modify an
existing keyslot in some way. In that scenario, "active" can
be updated to be allowed to be optional such that:
- active: true -> activate a currently inactive keyslot
- active: false -> deactivate a currently active keyslot
- active omitted -> modify a currently active keyslot
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
