[
https://issues.apache.org/jira/browse/HADOOP-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yi Liu updated HADOOP-10693:
----------------------------
Attachment: HADOOP-10693.6.patch
[~cmccabe], Thanks for the review.
{quote}
I was just asking you to change the type of the variables to unsigned, and then
you won't need any casts. It seems that you dropped the cast, but didn't change
the type to unsigned.
{quote}
My bad, I misunderstood your meaning. I update it.
{quote}
It's good that you changed the name of the test, but there are still some other
class names we should fix. Since the other stuff shows up in config XMLs, it's
probably even more important to use something readable.
{quote}
Oh, you mean this:-), now I update all of them in the new patch. I thought they
were checked in already and changing the name was big thing, so I only changed
the name in Test.
_AESCTRCryptoCodec -> AesCtrCryptoCodec_
_JCEAESCTRCryptoCodec -> JceAesCtrCryptoCodec_
_OpensslAesCtrCryptoCodec_
_OpensslCipher_
_TestCryptoStreamsWithOpensslAesCtrCryptoCodec_
{quote}
I added the "require" flags since previously we were having so much trouble
ensuring our builds contained what they were supposed to contain.
There is a way to pass java properties on to Surefire, but it's finicky. A
simpler approach might just be to do something like this:
{code}
Preconditions.checkState(NativeCodeLoader.buildSupportsOpenssl());
Assert.assertTrue(OpenSSLCipher.isNativeCodeLoaded());
{code}
We need to make sure that the build fails when there is an issue loading
libcrypto.so on Jenkins. Otherwise, we can never be sure about our test
coverage.
{quote}
I get your point. And you mean
{code}
if (NativeCodeLoader.buildSupportsOpenssl()) {
Assert.assertTrue(OpensslCipher.isNativeCodeLoaded());
}
{code}
Right? (We can't make precondition on {{buildSupportsOpenssl}} directly, it
will fail if build without Openssl) Now I add it in the new patch.
Furthermore, in linux the shared library for OpenSSL 1.0.0x and 1.0.1x both are
“libcrypto.so.1.0.0”, but AES-CTR is only supported in 1.0.1x. So I add
following in the new patch to check the detailed version (we are not able to
get whether its 1.0.0x and 1.0.1x from the suffix):
{code}
if (OPENSSL_LIBRARY AND OPENSSL_INCLUDE_DIR)
file(STRINGS "${OPENSSL_INCLUDE_DIR}/openssl/opensslv.h"
OPENSSL_VERSION_STR REGEX "^#define[\t ]+OPENSSL_VERSION_NUMBER[\t
]+0x[0-9][0-9][0-9][0-9][0-9][0-9].*")
string(REGEX MATCH 0x[0-9][0-9][0-9][0-9][0-9][0-9]..L OPENSSL_VERSION
"${OPENSSL_VERSION_STR}")
IF(${OPENSSL_VERSION} LESS 0x1000100fL)
SET(OPENSSL_VERSION_MATCHED FALSE)
ELSE()
SET(OPENSSL_VERSION_MATCHED TRUE)
ENDIF()
endif (OPENSSL_LIBRARY AND OPENSSL_INCLUDE_DIR)
{code}
If openssl exists, but the version is not sufficient, {{OpensslCipher.c}} will
not be compiled. If specifying {{require.openssl}}, but the version is not
sufficient, build will fail with error message “Openssl version is too low,
should be at least 1.0.1”.
> 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.5.patch,
> HADOOP-10693.6.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)
