[
https://issues.apache.org/jira/browse/HADOOP-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021250#comment-16021250
]
Steve Loughran commented on HADOOP-14448:
-----------------------------------------
SSEC is trouble; the tests are in because if you use the wrong key, you can't
even do MD operations. You cannot mix SSEC and SSES3 or SSEKMS on the same
bucket.
This may be a time to think about any future client-side encryption. There's a
patch for that, but I've said "wait until s3guard is in", and even then don't
like it, because you can get less data back in read() calls than the declared
length of the store. Everything will break
> Play nice with ITestS3AEncryptionSSEC
> -------------------------------------
>
> Key: HADOOP-14448
> URL: https://issues.apache.org/jira/browse/HADOOP-14448
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: HADOOP-13345
> Reporter: Sean Mackrory
>
> HADOOP-14035 hasn't yet been merged with HADOOP-13345, but it adds tests that
> will break when run with S3Guard enabled. It expects that certain filesystem
> actions will throw exceptions when the client-provided encryption key is not
> configured properly, but those actions may sometimes bypass S3 entirely
> thanks to S3Guard (for example, getFileStatus may not actually need to invoke
> s3GetFileStatus). If the exception is never thrown, the test fails.
> At a minimum we should tweak the tests so they definitely invoke S3 directly,
> or just skip the offending tests when anything but the Null implementation is
> in use. This also opens the larger question of whether or not S3Guard should
> be serving up metadata that is otherwise only accessible when an encryption
> key is provided.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
