[
https://issues.apache.org/jira/browse/HADOOP-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723238#comment-17723238
]
Steve Loughran commented on HADOOP-18638:
-----------------------------------------
there's always been that little secret that you could re-encrypt, but it's not
anything we've ever encouraged people to use.
I think the source file encryption settings should be preserved, it is what
"real" rename does; it also avoids the problem that renaming SSE-C data
requires the encryption key of the renaming fs matching that of the original
data, so it can decrypt/re-encrypt
The only S3-S3 copy exposed to the public filesystem API is the rename()
operation, so preserving source encryption seems right; treat the missing
return statement in the current code as a bug to fix
> define s3a encryption behaviour on copy
> ---------------------------------------
>
> Key: HADOOP-18638
> URL: https://issues.apache.org/jira/browse/HADOOP-18638
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Reporter: Ahmar Suhail
> Priority: Major
>
> When doing a copy, S3A always uses encryption configuration of the
> filesystem, rather than the source object. This behaviour may not have been
> intended, as in `RequestFactoryImpl.copyEncryptionParameters()` it does copy
> source object encryption properties
> [here|https://github.com/apache/hadoop/blob/trunk/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/impl/RequestFactoryImpl.java#L336]
> , but a missing return statement means it ends up using the FS settings
> anyway.
>
> Proposed:
> * If the copy is called by rename, always preserve source object encryption
> properties.
> * For all other copies, use current FS encryption settings.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
