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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exp/services/recoverysigner: add encrypt and decrypt commands #2746
exp/services/recoverysigner: add encrypt and decrypt commands #2746
Changes from all commits
2e24e69
010ef54
d9adfae
db21ae6
22f624f
598d26e
adcf23d
a142e95
12f6dd2
b694651
8bb682c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any tests for this, is that because of the use of the aws integration here? I think we need to figure out tests for these commands, this code is pretty important. Let's think about this separate to this PR though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly. We will have to think about the best way to mock this out. I will create an issue for this.
Speaking of this, I'm curious what you think about having a mock struct in non-test files. i.e. when it is ok to have one and when is not. I remember you mentioned you don't want to have a mock being part of the binary of production code, but we are doing that in the vibrant backend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only had an issue with the type being callable via the CLI, i.e. being able to use the mock in real production code, not having the type live there. If we do have types or functions intended only for testing but that need to be importable, let's keep them in their own package. If it's for the crypto package, put them in
cryptotest
. This pattern is pretty common I think.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. It does look like it is possible to the use the mock in real production with KMS_PROVIDER being set to
mock
in the vibrant backend. Maybe we need to address that.Yeah I usually realize that I have to do this if I have the import cycle issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#2750
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we don't. I think there might be some values to start the service with a KMS mock client in vibrant backend. Looks like this is done on purpose so that people can start the service locally and test the endpoints that use it.
I think the difference lies in the fact that the recovery signer can operate without configuring a KMS client because it is only used to encrypt the tink keyset whereas the vibrant backend cannot operate without configuring a KMS client because it is used to encrypt the data directly.
What do you think? Do you agree?