Hi Enrique,
I confirm this is an issue with IBM JRE (I have the very same pb on my
linux box).
Maven profile sounds a good short term solution to me. As Alex says, we
should find a way to build the server with any JVM asap, and then spend
some time finding a better solution for IBM JRE.
btw, I switcehd to Sun JVM 6 just to be able to build the server, sadly,
not something possible for those under AIX :(
Emmanuel
Alex Karasulu a écrit :
Or for a shorter term work around could you either disable the tests that
cause this failure. Or
perhaps just enable them as you did before to detect if the crypto
functionality is present and
if not bypass the test? This might be a nice quick fix then we can
take #4
as an option for the
long term?
Alex
On 5/23/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 5/23/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> Hmmm this may be an issue of some tests using SUN specific
classes. Enrique
> what do you think?
The IBM JRE's are notorious for not shipping with some widely used
crypto. Web services have the same problem. This isn't an issue that
"unlimited strength" policy will fix.
We have a couple options I'll throw out there:
1) We can require ApacheDS to build on certain VMs (just noting it as
an option ...).
2) We can require users of the IBM JRE to install a provider that
does support CTS mode, RC4/ARCFOUR, and possibly something else,
judging from the errors. Installing a provider is easy; one line in a
config file and a provider JAR in the right place. I would write
instructions for setting this up.
Something like:
$ cd /opt/ibm/java2-x86_64-50/jre/lib/ext
$ wget http://www.bouncycastle.org/download/bcprov-jdk15-136.jar
$ cd /opt/ibm/java2-x86_64-50/jre/lib/security
$ vi java.security
Add this line after the other providers, for example at position 6:
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
3) I can rework the Kerberos tests to use a Maven 2 profile,
something like -Dkerberos, like we do with integration and performance
tests. I can then group any tests using CTS mode, RC4/ARCFOUR,
AES-256, etc., to run using this profile.
4) I can modify the exception hierarchy to handle more missing cases.
Likely this is limited to 2-3 classes, so might not be too big of a
deal. Similarly the tests would get updated. The big issue here, for
me, is getting the right dev & test environment setup. If it's not
the platform but just the IBM JRE then that's easy; I install an IBM
JRE locally.
I'm thinking out loud here; pretty much the answer is to handle this
in the exception hierarchy (#4). Timing could be later this week or
early next.
Will 'maven.test.skip' hold things over for a few days? Or the
provider install in #2?
$ mvn -Dmaven.test.skip=true clean install
Enrique
Caused by: java.security.NoSuchAlgorithmException: Cipher mode: CTS not
found
at com.ibm.crypto.provider.AESCipher.engineSetMode(Unknown
Source)
at javax.crypto.Cipher$a_.a(Unknown Source)
... 35 more
java.security.NoSuchAlgorithmException: Cannot find any provider
supporting AES/CTS/NoPadding
