davidarcher edited a comment on issue #1823: HADOOP-16794 S3 Encryption key is not getting set properly during put operation. URL: https://github.com/apache/hadoop/pull/1823#issuecomment-582994184 > So what is proposed is > > If we have local SSE-KMS settings, use that > fall back to that on the source object > > What if we have local SSE-S3 enabled? would we want to switch for a simple rule: "if you have encryption set, renamed files pick it up; otherwise files encrypted with SSE-KMS keep their encryption" I'll defer to you for expected semantics here as I'm very new to this code base but my understanding is that this is the existing behavior for Copy operations for files encrypted with other SSE types. > As @mukund-thakur's patch currently has > > "files encrypted with SSE-KMS retain that encryption setting when renamed, irrespective of your client settings" > > I think I prefer the one in mukund's patch as its simpler to explain. Encryption with SSE-KMS is "sticky" Isn't it "files encrypted with SSE-KMS reset to the bucket default encryption when renamed, irrespective of your client settings" though? It seems a bit inconsistent that for other SSE types, renames don't change encryption settings (unless explicitly specified in the client settings) but for SSE-KMS, with this change, renames reset to whatever is specified as default encryption on the bucket (unless explicitly specified in the client settings).
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
