Re: [PATCH 02/13] qcrypto-luks: implement encryption key management

[Markus Armbruster]

Kevin Wolf <address@hidden> 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.