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

[raif at swiftdsl dot com dot au]

------- Comment #7 from raif at swiftdsl dot com dot au  2006-06-20 20:57 
-------
(In reply to comment #6)
> (In reply to comment #5)
> > ...could you
> > briefly explain the benefit of replacing the dependency on SystemProperties 
> > to
> > a dependency on gnu.java.security.action?  specifically, how can that 
> > achieve
> > the goal of producing standalone providers (i.e. for use by VMs not using 
> > GNU
> > Classpath).
> 
> The gnu.java.security package is included in the gnu-crypto.jar so a 
> dependency
> on GetPropertyAction keeps the jar self contained (see patches for
> configure/Makefile). Having explicit dependency on
> gnu.classpath.SystemProperties was a problem because it used 
> VMSystemProperties
> which is classpath specific. We will most likely need to provide
> gnu.java.security in one of the jars, whichever way we decide to extract 
> crypto
> specific code, wouldnt we? In that case, having this dependency does not cause
> a problem in my opinion.

makes sense.


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

furthermore, gnu.javax.crypto.* have to live in their own jar to make it easier
for publishers of applications with export restrictions.


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


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

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

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.

thoughts?


-- 


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