[
https://issues.apache.org/jira/browse/HADOOP-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14061279#comment-14061279
]
Colin Patrick McCabe commented on HADOOP-10735:
-----------------------------------------------
Thanks for working on this, Yi.
{code}
<property>
<name>hadoop.security.crypto.cipher.suite</name>
<value></value>
<description>
Cipher suite for crypto codec.
</description>
</property>
{code}
What's the default value here? In the code it's described as:
{code}
public static final String HADOOP_SECURITY_CRYPTO_CIPHER_SUITE_DEFAULT =
"AES/CTR/NoPadding";
{code}
{code}
public <U> List<Class<? extends U>> getClasses(String name,
Class<U> xface, List<Class<? extends U>> defaultValue) {
...
try {
Class<?> cls = getClassByName(c);
classes.add(cls.asSubclass(xface));
} catch (ClassCastException e) {
throw new IllegalArgumentException("Class " + c +
" is not a " + xface.getSimpleName(), e);
} catch (ClassNotFoundException e) {
throw new IllegalArgumentException(xface.getSimpleName() + " " + c +
" not found.", e);
}
}
{code}
The behavior in this patch is that if one of the classes the user specified
wasn't found, we get a hard failure (can't start up). I don't think this is
quite right.
Consider if there is a different codec added in a new version of Hadoop. If
specifying a missing codec as part of the list is a hard failure, management
software designed to work with multiple versions of hadoop (or just
configuration files and tutorials designed to work with multiple versions of
hadoop) are not going to be able to use the new codec.
I commented on this earlier:
bq. This doesn't make sense to me. Let's say I ask for the Foobar2000 codec,
but you don't have it (the class doesn't exist because you're running an older
version of Hadoop.) Then this is going to give you a null pointer exception and
nothing will work... the fallback fails completely.
The behavior we want is that if one class isn't found, we fall back to the next
class in the list (maybe with a log message.)
> 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, HADOOP-10735.002.patch,
> HADOOP-10735.003.patch, HADOOP-10735.004.patch, HADOOP-10735.005.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)
