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. 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.) [...] > 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. Max
signature.asc
Description: OpenPGP digital signature