I'm very happy that there is some discussion about this, and also very happy to see the Jira issue opened.
I would like to emphasize one point: I did try putting the bc jar in /jre/lib/ext and configuring java.security, and that caused WebSphere to not be able to start. This is exactly the #2 problem you list below. When I deploy my app, I have to send an ear file to a different government department, and they deploy it on their servers. They're very tight about security and configuration, and I'm sure they wouldn't want to mess around with the security settings. They host several applications on each server. So that just reinforces the notion that we need to implement a solution that doesn't require configuration at the system level. In the mean time, I'm writing my own class loader that I'll package in the xml-security jar, that extracts the Cipher and provider classes directly from jars in a directory (i.e. the app context + WEB-INF/lib). I consider it a temporary hack until the fix appears in xml-security or wss4j. Are there any ClassLoader experts in the group? I've hit a snag... cheers, md > -----Original Message----- > From: George Stanchev [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 18, 2007 6:26 PM > To: Fred Dushin > Cc: [EMAIL PROTECTED] > Subject: RE: [dev-crypto] Bug in Cipher class? > > > Hi Fred, > > I agree its hard to manage since all instantiations need to go > through the custom provider and I agree most calls are in > XML-Security. > > However it's a serious problem, and may be others can chime > in on whats > the best way to solve it. > > May be we can write a java.security.Security wrapper that instead of > hitting the global JCE registry, hits our own registry. That > wouldn't be > too hard to implement. Then we load that implementation along with the > BC provider and the classes within our context use us instead of the > global Security object. If a transforamtion can be satisfied by the BC > JCE provider > then we pass along an implementation from it, otherwise we > can delegate > to the system registry and try to find a transformation there. > > Of course adding the BC to the /jre/lib/ext and properly > registering it > there would solve the problem but that really creates a > strain on users. > > But you see the problem - if the thread context loader of WSS4J is > different than > the application loader (say a derivative) then there is a real chance > of screwing up (especially since WSS4J tries to put the BC at slot 2!) > by: > 1. screwed up as Michael was when the javax.crypto.* classes try to > instantiate > a provider from a classloader they are not permitted (lower > then them in > the hierarchy) to see > 2. Screw up other applications that try to do JCE > transformationss that > happen > to stumble upon our provider. > > The real solutions are 2 - either we run BC JCE alongside the > other JCE > providers > or run in isolation. > > Best Regards, > George > > -----Original Message----- > From: Fred Dushin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 18, 2007 3:34 PM > To: George Stanchev > Cc: [EMAIL PROTECTED] > Subject: Re: [dev-crypto] Bug in Cipher class? > > Hi George, > > Wouldn't this require that every call to XXX.getInstance(...) in WSS4J > be modified to specify a provider? > > In general, I actually think that's a good idea (though probably very > complex to manage!). > > But more to the point, I think many of these calls will not > be found in > WSS4J, but instead in Apache XML-Sec. > > Or am I missing something here? > > Thanks! > Fred > > > On Jul 18, 2007, at 12:39 PM, George Stanchev wrote: > > > An alternative solution would be to not go via the > > java.security.Security JCE registry and use the JCE > provider directly > > via XXX.getInstance(String transformation, Provider prov) > calls. But > > for some reason (and here the WSS4J developers can chime > > in) > > WSS4J relies on > > the Java 1.3 JCE interfaces which lack those methods and need to go > > via the security registry. > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply e-mail and > destroy all copies of the original message. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
