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

[vivekl at redhat dot com]

------- Comment #6 from vivekl at redhat dot com  2006-06-19 21:18 -------
(In reply to comment #5)
> i am not on IRC, so forgive me if this has been discussed there, but 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.

> what would be very helpful is to be able to produce, at least, two separate
> jars: one containing the strong stuff (classes and algorithms in
> gnu.javax.crypto), and another for Jessie.  this can be of immediate use to
> those packaging GNU Classpath with their applications under export-restricted
> conditions.
> 
> achieving this is much simpler since any dependencies on the main GNU 
> Classpath
> classes can remain as-is, and the problem is reduced to:
> 
> a. producing 3 or more jars (incl. the main GNU Classpath one), and
> b. ensuring that classes from the additional jars are found at runtime.
> 
> 
> does this sound reasonable?
> 

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? 

In my opinion we should make sure that these dont depend on classpath specific
classes. If all someone wants to do is, say, replace their BouncyCastle jar
with a gnu-crypto version, then having them to install the whole classpath jar
is probably not very nice. 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?

At the same time, glibj + these jars will serve the purposes of people running
on a classpath based VM. Export restricted usage can be carried out easily as
well.

Just my 2 cents...
Thanks,
Vivek


-- 

vivekl at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vivekl at redhat dot com


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