hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10735) Fall back AesCtrCryptoCodec implementation from OpenSSL to JCE if non native support.
Date Fri, 11 Jul 2014 22:05:05 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059421#comment-14059421

Colin Patrick McCabe commented on HADOOP-10735:

      StringTokenizer parser = new StringTokenizer(codecString, ",");
      while (parser.hasMoreElements()) {
        String c = parser.nextToken().trim();
        if (!c.isEmpty()) {

Seems kind of verbose.  How about just:
for (String c : Splitter.on(',').trimResults().omitEmptyStrings().split(codecString)) {

            if (!CryptoCodec.class.isAssignableFrom(cls)) {
              throw new IllegalArgumentException("Class " + c + 
                  " is not a CryptoCodec.");

The {{isAssignableFrom}} part is not necessary.  {{asSubclass}} will throw a {{ClassCastException}}
if the class can be cast to a subclass as requested.

  try {
      codec = ReflectionUtils.newInstance(klasses.get(0), conf);
    } catch (Exception e) {
      CryptoCodec fallback = null;
      for (int i = 1; i < klasses.size(); i++) {
        fallback = ReflectionUtils.newInstance(klasses.get(i), conf);

Don't special-case the first list element.  You can always have a boolean or something that
controls whether you print out "falling back to X"

        if (codec.getCipherSuite() == fallback.getCipherSuite()) {

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

It makes more sense to have a configuration key for the cipher suite you're using, and then
another set of configuration keys that determine which classes to use for those configuration

It seems to me that clients are not going to want fallback to a different cipher suite, if
there is nothing available for the current cipher suite.  They would not be able to read other
clients' files, or write files that other clients could handle, when using a different cipher
suite.  Clients they just want fallback between different implementations of the *same* cipher
suite.  So it makes sense to have separate config keys for "cipher suite" and "implementation

> 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
> 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

View raw message