Implement support for partial keys - #505
Conversation
Getting key backends with via method `GetKeyBackend` defers loading of key material until it is actually required. Key material which is not required does not have to be present on disk, such that e.g. `verify` could run without PK and KEK, only requiring db key material.
All `KeyBackend`s are interfaces, which means they can be `nil` as well. Actively using this means they do not have to be set immediately, but only if really needed, paving the way for partial key support. This comes with the downside that direct calls to the `KeyBackend`s instead of using the `GetKeyBackend` method could result in nil pointer references, which will be resolved in another commit.
Encourage the use of `GetKeyBackend` and `UpdateKeyBackend` to avoid direct calls that could result in nil pointer references.
By supplying `--partial`, `create-keys` now only generates the specified key pair instead of all three `PK`, `KEK`, `db`.
There already is a check of the key type when creating new keys, which can be used to drop the additional check of the given CLI flags. This change reduces similar code paths.
|
Looking through the code I stumbled upon a small bug and added a fixup: e54b8f3 |
|
Quickly reviewing this code and I have no immediate comments. I'll need to sit down a bit more with this and test run things as there is a lack of test coverage in |
e54b8f3 to
cd24fa8
Compare
If I can help with something, let me know!
The fixup unfortunately does not fit, because it uses a method which is introduced by a later commit. I added a proper fixup instead and renamed the initial commit to better reflect that it is trying to keep the functionality of |
2 participants
While this PR admittedly is rather massive, I tried to split it into digestible commits for easier review.
The first three commits implement lazy loading of key backends from disk, namely PK, KEK, and db.
This will already close Image signature/verification fails if PK or KEK are missing #356.
The next three commits change the use of
KeyHierarchyby turning a few functions into struct methods, which better fits the understanding I got from reading the code: after initializing a new object withNewKeyHierarchyit can be filled withReadKey,CreateKey, orImportKey, and then be used for operations such as sign/verify/save.Please let me know if you agree with this approach.
The next three commits prepare and implement partial key generation by adding
--partialtosbctl create-keysThe last commit simplifies CLI input checks, which I stumbled upon when implementing partial key support when creating keys