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

[vivekl at redhat dot com]

------- Comment #8 from vivekl at redhat dot com  2006-06-21 18:31 -------
(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. Are there any
tricks that we can use to get around this problem?
> > In my opinion we should make sure that these dont depend on classpath 
> > specific
> > classes.
> 
> absolutely.  testing the resulting jars with an RI 1.4, using Tony's latest
> Harness, and the Mauve tests is a minimum.
Agreed.

> > We only have a few dependencies on
> > gnu.classpath.debug, gnu.classpath.Configuration, gnu.classpath.ByteArray 
> > etc.
> > in most of these packages which we could remove?
> 
> gnu.classpath.debug.* can be jarred in its own jar.
This will probably work. I will post something about this on the classpath list
to get other people's comments.

> 
> ByteArray is only used by RSACipherImpl and can probably be relocated to
> gnu.java.security.util.
This sounds good.

> 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.?)...

Thanks!


-- 


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