You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Fred Dushin (JIRA)" <ji...@apache.org> on 2008/04/04 22:33:24 UTC
[jira] Commented: (WSS-56) WSS4j statically inserts Bouncycastle
and Juice in list of JCE providers
[ https://issues.apache.org/jira/browse/WSS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585749#action_12585749 ]
Fred Dushin commented on WSS-56:
--------------------------------
The ticket should be closeable. I do not have rights to do that, AFAIK.
> WSS4j statically inserts Bouncycastle and Juice in list of JCE providers
> ------------------------------------------------------------------------
>
> Key: WSS-56
> URL: https://issues.apache.org/jira/browse/WSS-56
> Project: WSS4J
> Issue Type: Bug
> Environment: IBM JDK 1.4.2 (AIX)
> Reporter: Fred Dushin
>
> As described in email
> The WSSConfig class insists on inserting the Bouncycastle JCE provider "first" (or second...) in the list of JCE providers, if it can be found on the classpath.
> The IBM JDK does not seem terribly appreciative of this fact, as the following test case illustrates. For me, on AIX, using IBM's 1.4.02 JDK, the following code fails with "java.security.KeyStoreException: jks not found". If I add the Bouncycastle provider to the end of the list of providers, I don't get the error.
> public class Test {
> public static void
> main(
> String[] argv
> ) {
> try {
> java.security.Security.insertProviderAt(
> (java.security.Provider)
> Class.forName(
> "org.bouncycastle.jce.provider.BouncyCastleProvider"
> ).newInstance(),
> 2
> );
> final java.security.KeyStore keystore =
> java.security.KeyStore.getInstance(
> "jks"
> );
> java.io.FileInputStream fis =
> new java.io.FileInputStream(
> "alice.jks"
> );
> keystore.load(fis, "password".toCharArray());
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> Truss on AIX shows some intersting behavior. It looks like the JVM can't locate org/bouncycastle/jce/provider/JDKMessageDigest$SHA1.class, but it's a bit hard to decipher.
> In any event, I think they fact that the WSS4j toolkit is statically injecting a provider into the JVM at runtime is pretty wrong, especially in library code that has to co-exist peacefully in an otherwise potentially hostile environment...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org