[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [PATCH 02/13] qcrypto-luks: implement encryption key management
Date: Thu, 30 Jan 2020 15:53:17 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]