feat: Merge changes from 3.1.2 #583
Conversation
#560) * fix: issue when a DynamoDB Set attribute is marked as SIGN_ONLY in the AWS Database Encryption SDK (DB-ESDK) for DynamoDB. DB-ESDK for DynamoDB supports SIGN_ONLY and ENCRYPT_AND_SIGN attribute actions. In version 3.1.0 and below, when a Set type is assigned a SIGN_ONLY attribute action, there is a chance that signature validation of the record containing a Set will fail on read, even if the Set attributes contain the same values. The probability of a failure depends on the order of the elements in the Set combined with how DynamoDB returns this data, which is undefined. This update addresses the issue by ensuring that any Set values are canonicalized in the same order while written to DynamoDB as when read back from DynamoDB. See: https://github.com/aws/aws-database-encryption-sdk-dynamodb-java/DecryptWithPermute/README.md for additional details
* feat: add ResolveAttribute
* feat: implement beacon styles
* feat: dont use internal, because it is reserved in dotnet
* feat: repair dependencies in item encryptor et al
* feat: Global Parts List * add BeaconStylesSearchableEncryptionExample.java
* feat: repair dotnet build, enable net ci
* chore: update MPL submodule, bouncycastle, Dafny 4.2
* feat: change twinned beacons to shared beacons
| basket.add("strawberry"); | ||
| basket.add("blueberry"); | ||
| basket.add("blackberry"); | ||
| basket.add("blueberry"); | ||
| basket.add("strawberry"); |
There was a problem hiding this comment.
Why was this change made?
There was a problem hiding this comment.
Because we changed how things are stored.
Before, encrypted sets maintained their original order.
Now, encrypted sets come back sorted.
There was a problem hiding this comment.
But the order shouldn't semantically matter. If we get a failure in our example when the input set isn't in order, then we are doing something wrong in our example.
There was a problem hiding this comment.
I see that we check equality on L265. It is annoying that the string set attribute type's equality isn't overridden such that order doesn't matter... This is fine as is, as I think it would be too confusing in this example to explain a more complex way to check equality, when that is not the focus of the example.
README.md
Outdated
| @@ -59,7 +59,7 @@ To use the DB-ESDK for DynamoDB in Java, you must have: | |||
| * **Via Gradle Kotlin** | |||
| In a Gradle Java Project, add the following to the _dependencies_ section: | |||
| ```kotlin | |||
| implementation("software.amazon.cryptography:aws-database-encryption-sdk-dynamodb:3.1.0") | |||
| implementation("software.amazon.cryptography:aws-database-encryption-sdk-dynamodb:3.1.1") | |||
There was a problem hiding this comment.
| implementation("software.amazon.cryptography:aws-database-encryption-sdk-dynamodb:3.1.1") | |
| implementation("software.amazon.cryptography:aws-database-encryption-sdk-dynamodb:3.1.2") |
README.md
Outdated
| @@ -92,7 +92,7 @@ To use the DB-ESDK for DynamoDB in Java, you must have: | |||
| <dependency> | |||
| <groupId>software.amazon.cryptography</groupId> | |||
| <artifactId>aws-database-encryption-sdk-dynamodb</artifactId> | |||
| <version>3.1.0</version> | |||
| <version>3.1.1</version> | |||
There was a problem hiding this comment.
| <version>3.1.1</version> | |
| <version>3.1.2</version> |
project.properties
Outdated
| @@ -1,4 +1,4 @@ | |||
| projectJavaVersion=3.1.0 | |||
There was a problem hiding this comment.
We need to update this as well.
(ideally we'd have the README pull from this file, but that doesn't need to block these changes)
|
closing in favor of #588 |
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.