On Tue, 2020-01-28 at 17:32 +0000, Daniel P. Berrangé wrote:
> 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.
>
> 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.
>
> This avoids the problem with being unable to specify a
> null for StrOrNull on the command line too.
I fully support this idea.
If no objections from anybody else, I'll do it this way.
Best regards,
Maxim Levitsky
>
> Regards,
> Daniel
