[Bug crypto/27649] Addition of --standalone-crypto configure option

[raif at swiftdsl dot com dot au]

------- Comment #9 from raif at swiftdsl dot com dot au  2006-06-22 10:15 
-------
(In reply to comment #8)
> (In reply to comment #7)
> > > ...
> > > The other patch for the --enable-standalone-crypto is, in hindsight, 
> > > incorrect.
> > > Extracting a JCE jar (javax.crypto...), a crypto provider jar
> > > (gnu.java.security, gnu.javax.crypto...), and a jessie jar from the main
> > > classpath jar is probably preferable?
> > 
> > i don't think you have to worry about separating javax.crypto packages.  
> > these
> > are part of RIs (since 1.4 i believe) and can safely remain with the main 
> > GNU
> > Classpath jar (or jars in the future).
> 
> Actually this brings up another point. When using proprietary 1.4 VMs and 
> using
> our crypto jars as a provider, the proprietary JCE API implementations seem to
> check if the provider is signed but we dont/cant/wont have officially signed
> jars for these
> (http://www.gnu.org/software/gnu-crypto/manual/Installing-the-JCE-Classes.html#Installing%20the%20JCE%20Classes
> ) we almost have to fake out these VMs to use our JCE code (javax.crypto...).
> So far we have been doing this by placing a massive crypto.jar in the endorsed
> directory of the JRE so our classes gets loaded before the proprietary
> implementation. As a result, having a jce jar might be necessary.

good catch!


> Are there any
> tricks that we can use to get around this problem?

for 1.4 you can specify the jars on the bootclasspath.  for 1.5 i never tried.


> > the only problem is Configuration!  we need this or something similar to cut
> > down on the trace/logging.  having a similar class in the gnu.java.security
> > hierarchy is an alternative.
> > 
> 
> This should be pretty easy. A quick idea is to use a simple proxy as you
> suggested. For instance, the configuration proxy for crypto in
> gnu.java.security could just use reflection to check if the
> gnu.classpath.Configuration class exists. If it does, then it can just cache
> things from gnu.classpath.Configuration, if not it can define its own defaults
> which can be overriden (perhaps a java property or two for debug etc.?)...

how about using a gnu.java.security.Configuration.java.in that, for the time
being, has the single static field DEBUG --similar to the
gnu.classpath.Configuration.java.in.  configure can take care of the generation
of the concrete source file without needing to resort to reflection.

besides, if the publisher does not have the other Classpath jars, reflection
will not find any gnu.classpath.Configuration class anyway.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27649