On Wed, 2020-02-26 at 08:28 +0100, Markus Armbruster wrote:
> Max Reitz <mre...@redhat.com> writes:
>
> > On 25.02.20 17:48, Markus Armbruster wrote:
> > > Max Reitz <mre...@redhat.com> writes:
> > >
> > > > On 15.02.20 15:51, Markus Armbruster wrote:
> > > > > Review of this patch led to a lengthy QAPI schema design discussion.
> > > > > Let me try to condense it into a concrete proposal.
> > > > >
> > > > > This is about the QAPI schema, and therefore about QMP. The
> > > > > human-friendly interface is out of scope. Not because it's not
> > > > > important (it clearly is!), only because we need to *focus* to have a
> > > > > chance at success.
> > > > >
> > > > > I'm going to include a few design options. I'll mark them "Option:".
> > > > >
> > > > > The proposed "amend" interface takes a specification of desired state,
> > > > > and figures out how to get from here to there by itself. LUKS
> > > > > keyslots
> > > > > are one part of desired state.
> > > > >
> > > > > We commonly have eight LUKS keyslots. Each keyslot is either active
> > > > > or
> > > > > inactive. An active keyslot holds a secret.
> > > > >
> > > > > Goal: a QAPI type for specifying desired state of LUKS keyslots.
> > > > >
> > > > > Proposal:
> > > > >
> > > > > { 'enum': 'LUKSKeyslotState',
> > > > > 'data': [ 'active', 'inactive' ] }
> > > > >
> > > > > { 'struct': 'LUKSKeyslotActive',
> > > > > 'data': { 'secret': 'str',
> > > > > '*iter-time': 'int } }
> > > > >
> > > > > { 'struct': 'LUKSKeyslotInactive',
> > > > > 'data': { '*old-secret': 'str' } }
> > > > >
> > > > > { 'union': 'LUKSKeyslotAmend',
> > > > > 'base': { '*keyslot': 'int',
> > > > > 'state': 'LUKSKeyslotState' }
> > > > > 'discriminator': 'state',
> > > > > 'data': { 'active': 'LUKSKeyslotActive',
> > > > > 'inactive': 'LUKSKeyslotInactive' } }
> > > >
> > > > Looks OK to me. The only thing is that @old-secret kind of works as an
> > > > address, just like @keyslot,
> > >
> > > It does.
> > >
> > > > so it might also make sense to me to put
> > > > @keyslot/@old-secret into a union in the base structure.
> > >
> > > I'm fine with state-specific extra adressing modes (I better be, I
> > > proposed them).
> > >
> > > I'd also be fine with a single state-independent addressing mode, as
> > > long as we can come up with sane semantics. Less flexible when adding
> > > states, but we almost certainly won't.
> > >
> > > Let's see how we could merge my two addressing modes into one.
> > >
> > > The two are
> > >
> > > * active
> > >
> > > keyslot old-secret slot(s) selected
> > > absent N/A one inactive slot if exist, else error
> > > present N/A the slot given by @keyslot
> >
> > Oh, I thought that maybe we could use old-secret here, too, for
> > modifying the iter-time.
>
> Update in place is unsafe.
>
> > But if old-secret makes no sense for
> > to-be-active slots, then there’s little point in putting old-secret in
> > the base.
> >
> > (OTOH, specifying old-secret for to-be-active slots does have a sensible
> > meaning; it’s just that we won’t support changing anything about
> > already-active slots, except making them inactive. So that might be an
> > argument for not making it a syntactic error, but just a semantic error.)
>
> Matter of taste. I like to keep simple things syntactic, and thus
> visible in introspection.
>
> > [...]
> >
> > > Note we we don't really care what "inactive, both absent" does. My
> > > proposed semantics are just the most regular I could find. We can
> > > therefore resolve the conflict by picking "active, both absent":
> > >
> > > keyslot old-secret slot(s) selected
> > > absent absent one inactive slot if exist, else error
> > > present absent the slot given by @keyslot
> > > absent present all active slots holding @old-secret
> > > present present the slot given by @keyslot, error unless
> > > it's active holding @old-secret
> > >
> > > Changes:
> > >
> > > * inactive, both absent: changed; we select "one inactive slot" instead of
> > > "all slots".
> > >
> > > "All slots" is a no-op when the current state has no active keyslots,
> > > else error.
> > >
> > > "One inactive slot" is a no-op when the current state has one, else
> > > error. Thus, we no-op rather than error in some states.
> > >
> > > * active, keyslot absent or present, old-secret present: new; selects
> > > active slot(s) holding @old-secret, no-op when old-secret == secret,
> > > else error (no in place update)
> > >
> > > Can do. It's differently irregular, and has a few more combinations
> > > that are basically useless, which I find unappealing. Matter of taste,
> > > I guess.
> > >
> > > Anyone got strong feelings here?
> >
> > The only strong feeling I have is that I absolutely don’t have a strong
> > feeling about this. :)
> >
> > As such, I think we should just treat my rambling as such and stick to
> > your proposal, since we’ve already gathered support for it.
>
> Thanks!
So in summary, do I have the green light to implement the Markus's proposal as
is?
Best regards,
Maxim Levitsky
