[
https://issues.apache.org/jira/browse/HADOOP-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14044823#comment-14044823
]
Colin Patrick McCabe commented on HADOOP-10693:
-----------------------------------------------
bq. Actually this is already included in the latest patch HADOOP-10693.2.patch.
Yeah, you're right. I was looking at v1 of the patch when I made that comment.
bq. I get your point, I will handle the fallback in HADOOP-10735.... I’m
thinking we can do it more simpler: If openssl native is not available, in
OpenSSLAESCTRCryptoCodec, we use javax.crypto.Cipher instead of
org.apache.hadoop.crypto.OpenSSLCipher if fallback is allowed by configuration.
JCE is always available, we don’t need a comma list, because fallback codec
should be the same algorithm and padding, it’s better not allowed user to
configure. Otherwise if user configure several codecs, different codec may be
chose in different environments, decryption may fail.
OK. Let's deal with this in HADOOP-10735, then.
There are a bunch of warnings that this code generates that we should fix:
{code}
/home/cmccabe/hadoop3/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/crypto/OpenSSLCipher.c:
In function ‘Java_org_apache_hadoop_cry
pto_OpenSSLCipher_update’:
/home/cmccabe/hadoop3/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/crypto/OpenSSLCipher.c:271:3:
warning: pointer targets in passi
ng argument 2 of ‘dlsym_EVP_CipherUpdate’ differ in signedness [-Wpointer-sign]
/home/cmccabe/hadoop3/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/crypto/OpenSSLCipher.c:271:3:
note: expected ‘unsigned char *’
but argument is of type ‘char *’
/home/cmccabe/hadoop3/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/crypto/OpenSSLCipher.c:271:3:
warning: pointer targets in passi
ng argument 4 of ‘dlsym_EVP_CipherUpdate’ differ in signedness [-Wpointer-sign]
/home/cmccabe/hadoop3/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/crypto/OpenSSLCipher.c:271:3:
note: expected ‘const unsigned ch
ar *’ but argument is of type ‘char *’
/home/cmccabe/hadoop3/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/crypto/OpenSSLCipher.c:
In function ‘Java_org_apache_hadoop_cry
pto_OpenSSLCipher_doFinal’:
/home/cmccabe/hadoop3/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/crypto/OpenSSLCipher.c:314:3:
warning: pointer targets in passi
ng argument 2 of ‘dlsym_EVP_CipherFinal_ex’ differ in signedness
[-Wpointer-sign]
/home/cmccabe/hadoop3/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/crypto/OpenSSLCipher.c:314:3:
note: expected ‘unsigned char *’
but argument is of type ‘char *’
{code}
Seems like they are related to using {{char*}} instead of {{unsigned char*}}
bq. Add test cases TestCryptoCodec#testJCEAESCTRCryptoCodec and
TestCryptoCodec#testOpenSSLAESCTRCryptoCodec. Add TestOpenSSLCipher. We
originally had TestCryptoStreamsWithOpenSSLAESCTRCryptoCodec
Thanks.
I ran {{TestCryptoCodec}} and it succeeded whether or not {{openssl.so}} was
installed. Can you make the test fail when {{\-Drequire.openssl}} is specified
and {{OpenSSLAESCTRCryptoCodec}} is not available? You should be able to check
{{System#getProperty}} or something like that. That way we could be sure our
test was covering this on upstream Jenkins.
A comment about naming. I find names like {{testJCEAESCTRCryptoCodec}} awfully
hard to read. Once you get 10 capital letters in a row, it just kind of mashes
together. I would prefer something like {{testJceAesCtrCryptoCodec}}, where we
capitalize only the first letter of each acronym. I think it would make sense
to rename some of this stuff in that way... what do you think?
{code}
jbyte *jKey = (*env)->GetByteArrayElements(env, key, NULL);
jbyte *jIv = (*env)->GetByteArrayElements(env, iv, NULL);
if (jKey == NULL || jIv == NULL) {
THROW(env, "java/lang/InternalError", "Cannot get bytes array.");
return (jlong)0;
}
{code}
Think about what happens if we manage to get {{jKey}}, but getting {{jlv}}
fails. Then we'll throw, but never call {{ReleaseByteArrayElements}} on
{{jKey}}.
> Implementation of AES-CTR CryptoCodec using JNI to OpenSSL
> ----------------------------------------------------------
>
> Key: HADOOP-10693
> URL: https://issues.apache.org/jira/browse/HADOOP-10693
> 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-10693.1.patch, HADOOP-10693.2.patch,
> HADOOP-10693.3.patch, HADOOP-10693.4.patch, HADOOP-10693.patch
>
>
> In HADOOP-10603, we have an implementation of AES-CTR CryptoCodec using Java
> JCE provider.
> To get high performance, the configured JCE provider should utilize native
> code and AES-NI, but in JDK6,7 the Java embedded provider doesn't support it.
>
> Considering not all hadoop user will use the provider like Diceros or able to
> get signed certificate from oracle to develop a custom provider, so this JIRA
> will have an implementation of AES-CTR CryptoCodec using JNI to OpenSSL
> directly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
