[
https://issues.apache.org/jira/browse/HADOOP-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056567#comment-14056567
]
Colin Patrick McCabe commented on HADOOP-10735:
-----------------------------------------------
{code}
conf.set(HADOOP_SECURITY_CRYPTO_CODEC_CLASS_KEY,
OpensslAesCtrCryptoCodec.class.getName());
+ conf.set(HADOOP_SECURITY_CRYPTO_CODEC_FALLBACK_CLASS_KEY,
+ JceAesCtrCryptoCodec.class.getName());
{code}
Rather than having two keys, we should just make the
HADOOP_SECURITY_CRYPTO_CODEC_CLASS_KEY contain a comma-separated list of
classes to try. This is a lot clearer, and makes it easy to have 2 fallbacks
if we want later... or 0. etc. Reading the comma-separated list is trivial
with String.split or similar
{code}
+ public void checkAvailable() throws GeneralSecurityException {
{code}
Why not just have the constructor throw an exception if the Codec isn't usable?
GeneralSecurityException doesn't really seem like the right thing either...
there's no security violation going on here. One of the "resource unavailable"
etc. type exceptions is probably what you want here.
> Fall back AesCtrCryptoCodec implementation from OpenSSL to JCE if non native
> support.
> -------------------------------------------------------------------------------------
>
> Key: HADOOP-10735
> URL: https://issues.apache.org/jira/browse/HADOOP-10735
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: security
> Affects Versions: fs-encryption (HADOOP-10150 and HDFS-6134)
> Reporter: Yi Liu
> Assignee: Yi Liu
> Fix For: fs-encryption (HADOOP-10150 and HDFS-6134)
>
> Attachments: HADOOP-10735.001.patch
>
>
> If there is no native support or OpenSSL version is too low not supporting
> AES-CTR, but {{OpensslAesCtrCryptoCodec}} is configured, we need to fall back
> it to JCE implementation.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
