Fix handling of SSE-C keys when copying unencrypted to encrypted objects or objects with different keys#9559
Fix handling of SSE-C keys when copying unencrypted to encrypted objects or objects with different keys#9559
Conversation
|
Awesome! Thanks @ashovlin 👏 |
|
Hi @ashovlin when do you think we could get this merged? 🙂 |
4c38f23 to
dddefe2
Compare
hssyoo
left a comment
There was a problem hiding this comment.
Looks good. But for discussion:
aws s3 cp s3://$bucket/ssec.txt decrypt.txt --sse-c AES256 --sse-c-key $key_1works, but I can see a case for applying--sse-c-copy-source/--sse-c-copy-source-keyto the object that's originating to S3.
GetObject itself uses SSECustomerAlgorithm over CopySourceSSECustomerAlgorithm, so isn't the current S3->local behavior correct?
Ah, maybe it's more open to interpretation then:
|
|
Hi @ashovlin & @hssyoo, following up on the PR after taking over from @FilipPyrek. Happy to provide any inputs to move this forward 👍 Our main usecase at Deepnote was summarized by Filip in this thread: #8345 (comment) |
…cts or objects with different keys
dddefe2 to
ebe7c06
Compare
Issue #, if available: #6012, and supersedes #8345
Description of changes: When copying a file that originates in S3, the high level
aws s3commands make aHeadObjectcall for the file that is being copied.When using server-side encryption with customer-provided keys (SSE-C), callers can specify the key for the source object(s)
--sse-c-copy-source/--sse-c-copy-source-keyand/or the destination object (--sse-c/--sse-c-key).The CLI is incorrectly handling this for S3 -> S3 copies, by applying the destination key to the source object.
aws s3 cp s3://$bucket/file.txt s3://$bucket/ssec-copy-c.txt --sse-c AES256 --sse-c-key $key_1aws s3 cp s3://$bucket/ssec.txt s3://$bucket/ssec-copy-diff-key.txt --sse-c-copy-source AES256 --sse-c-copy-source-key $key_1 --sse-c AES256 --sse-c-key $key_2Arguably Incorrect Behavior, Leaving for Backwards Compatibility
I think we're arguably handling S3 -> local copies as well.
aws s3 cp s3://$bucket/ssec.txt decrypt.txt --sse-c AES256 --sse-c-key $key_1works, but I can see a case for applying--sse-c-copy-source/--sse-c-copy-source-keyto the object that's originating to S3. But I'm preserving this behavior for backwards compatibility, the updated logic only runs for S3 -> S3 copies.Manual Testing
I didn't add new integration tests, but manually ran the following
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.