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!
