Split Encryptable/Decryptable trait into encryption and key retrieval #297
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
No New Or Fixed Issues Found |
MGibson1
reviewed
Oct 30, 2023
| impl<T: Encryptable<Output>, Output> Encryptable<Option<Output>> for Option<T> { | ||
| fn encrypt(self, enc: &EncryptionSettings, org_id: &Option<Uuid>) -> Result<Option<Output>> { | ||
| self.map(|e| e.encrypt(enc, org_id)).transpose() | ||
| impl<T: KeyEncryptable<Output> + LocateKey, Output> Encryptable<Output> for T { |
MGibson1
approved these changes
Oct 30, 2023
dani-garcia
added a commit
that referenced
this pull request
Nov 3, 2023
## Type of change ``` - [ ] Bug fix - [ ] New feature development - [x] Tech debt (refactoring, code cleanup, dependency upgrades, etc) - [ ] Build/deploy pipeline (DevOps) - [ ] Other ``` ## Objective After #297, there were some places in the secrets manager parts of the code that used EncryptionSettings to encrypt directly, instead of dealing with the Encryptable/KeyEncryptable trait. This PR removes those uses so that all encryption opearations have to go through Encryptable/KeyEncryptable.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Type of change
Objective
At the moment, the
Encryptable/Decryptabletrait handles both encryption/decryption and key retrieval. The goal of this PR is to split this trait into two parts, one part that only handles encryption/decryption (and thus will be able to be moved into a separatebitwarden-cryptocrate, if we want), and another part that handles retrieving the corresponding encryption key for each model object.Code changes
What was the
Encryptable/Decryptabletrait has been split into multiple parts:KeyEncryptable/KeyDecryptable: This receives only the encryption key and handles encryption/decryption only. The name of the interface was chosen to match the currentEncString::decrypt_with_key, which this replaces.LocateKey, which is implemented by types that know the type of key they need. For example aFolderalways uses the user key and aCipheruses the user key or one of the organization keys depending on itsorganization_idfield.Encryptable/Decryptable, this is now a thin compatibility layer between the previously mentioned two, to keep the existing API for the moment and keep the changes in this PR to a minimum. In the future we might decide that it's not necessary.With these changes, any models should implement
KeyEncryptable/KeyDecryptableonly, andLocateKeyif applicable, but neverEncryptable/Decryptabledirectly.Some of these changes will be more fleshed out in the future to avoid cluttering this PR, so I expect this won't look perfect:
LocateKeyandEncryptablehave an interface likeenc: &EncryptionSettings, org_id: &Option<Uuid>. The organization parameter is mostly superfluous now and will be removed in the future: Objects that implementLocateKeydo not use it, while objects which don't implement it should be provided the keys directly.EncStringis implementingLocateKeynow, which goes against the explanation above. This is to avoid refactoring some secrets manager code, which I'll do on a later PR.EncryptionSettingswill change in the future, specially theget_keyimplementation, to be more generic. It also contains anencryptfunction that shouldn't be there, but is used in a couple of spots of the code base and I'll remove on a later PR.KeyEncryptable/KeyDecryptableonly handlesSymmetricCryptoKey, this will be made more generic over key type.