Kevin Wolf <kw...@redhat.com> writes: > Am 30.01.2020 um 13:53 hat Daniel P. Berrangé geschrieben: [...] >> 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. > > The general idea of the amend interface is more that you describe a > desired state rather than operations to achieve it.
Point taken. >> 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 > > This distinction feels artificial to me. All three operations just > change the content of a keyslot. Whether it contained a key or not in > the old state shouldn't make a difference for how to get a new value > (which could be a new key or just an empty keyslot) written to it. *If* you can get it to fail only safely. Can you? > Making an omitted key mean something different from the other options so > that it's not just defaulting to one of them is problematic, too. We > have at least one place where it works like this (backing files) and it > tends to give us headaches. Seconded.
