-
Notifications
You must be signed in to change notification settings - Fork 26
Texastony/release hv 2 #296
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
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: Eric Crockett <[email protected]>
The encyrption context on hierarchical materials is all the encryption context, not only any custom values set by the customer on branch key creation.
A branch key version is a v4 UUID. As such it can be converted to 16 bytes. Also, the Encrypted Key is variable. It is whatever length the encryption key is for the given algorithm suite.
* feat: Make sure that storm caching settings are reasonable It was possible to configure a hierarchical keyring with storm tracking settings that resulted in poor caching performance. If the grace period is greater than the TTL, this results in items being immediately retried.
Co-authored-by: José Corella <[email protected]>
0 and `null` are both OK. This is how the Java type conversion works for the MPL Dafny.
Discovery and changing the region of a KMS key on decrypt do not mutate the customer input. This aligns with customer intent. Further the behavior of the code is to use the provided key directly #267 underspecified how branch keys should be created so this PR rolls back that change.
for supporting features such as custom CMMs, keyrings, etc.
* chore: clarify and update the storm tracking cache
…sion in Materials
|
||
- `KeyId` MUST be the `kms-arn` | ||
- `NumberOfBytes` MUST be 32. | ||
- `EncryptionContext` MUST be the `encryption-context` |
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.
Does this mean the input encryptionContext
?
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.
Yes.
In my opinion, it is best if there is one and only one definition of Encryption Context.
Since it is a parameter on the input, it should be the input's Encryption Context.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Check any applicable: