Encryption context should be required everywhere but the initial user entry points #54
Comments
seebees
added a commit
to seebees/aws-encryption-sdk-javascript
that referenced
this issue
Jul 15, 2019
resolves aws#54 1. browser/node encrypt function public api should match 1. Encryption context should _only_ be optional in the public interface 1. Encryption context moved into cryptographic materials Internally, it is much more consistent to require an encryption context. Moving the encryption context onto the cryptographic materials brings them in line with the python keyring implementation. It also makes control of the encryption context in the CMM and **not** the keyrings very clear in the interface. NOTE: encrypt in encrypt-node now expects `encryptionContext` instead of `context`. This is **ONLY** done because the project is still in beta.
seebees
added a commit
that referenced
this issue
Jul 26, 2019
resolves #54 1. browser/node encrypt function public api should match 1. Encryption context should _only_ be optional in the public interface 1. Encryption context moved into cryptographic materials Internally, it is much more consistent to require an encryption context. Moving the encryption context onto the cryptographic materials brings them in line with the python keyring implementation. It also makes control of the encryption context in the CMM and **not** the keyrings very clear in the interface. NOTE: encrypt in encrypt-node now expects `encryptionContext` instead of `context`. This is **ONLY** done because the project is still in beta.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are a lot of points in the codebase that accept an optional encryption context and default to an empty object if so. We should only do that default value assignment once, at the top-level user interface. Everywhere else, we should require that it is actually provided.
The text was updated successfully, but these errors were encountered: