Bug 27649 - Addition of --standalone-crypto configure option
Summary: Addition of --standalone-crypto configure option
Status: ASSIGNED
Alias: None
Product: classpath
Classification: Unclassified
Component: crypto (show other bugs)
Version: 0.92
: P3 enhancement
Target Milestone: ---
Assignee: Raif S. Naffah
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-17 20:43 UTC by Vivek Lakshmanan
Modified: 2006-07-14 05:53 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-06-18 00:36:05


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vivek Lakshmanan 2006-05-17 20:43:21 UTC
It would be useful if gnu-crypto specific jars could be created for use as a standalone security provider. Addition of a configure script option like --standalone-crypto which produces the standalone jars like gnu-crypto-2.1.0 did, would be very benificial for this purpose.
Comment 1 Casey Marshall 2006-05-18 07:11:31 UTC
As we discussed on IRC, a good compromise here is to split off Classpath's security providers into their own jar(s), when we build the library. This would also have the side benefit of making packaging Classpath for export-restricted scenarios easier: if all the crypto was compiled into a single jar, all a packager has to do is remove that jar from his distribution.

There aren't any technical hurdles in doing this. There are some internal dependencies that our providers have, but they are few, and can be well-documented for people who want to just use Classpath's security providers.
Comment 2 Vivek Lakshmanan 2006-06-07 23:36:52 UTC
Some fixes to facilitate the separation of gnu-crypto into seperate jar has been posted for review:
http://developer.classpath.org/pipermail/classpath-patches/2006-June/002635.html
Comment 3 Vivek Lakshmanan 2006-06-09 18:13:26 UTC
Please refer to the patch in:
http://developer.classpath.org/pipermail/classpath-patches/2006-June/002696.html

In combination with the earlier patch, the requirements for this enhancement are met. Perhaps we would prefer providers split up into smaller jars? Anyway, the above patch should provide a good starting point.
Comment 4 Raif S. Naffah 2006-06-14 09:33:35 UTC
Casey,

if you're not already working on this one, i'll take it.
Comment 5 Raif S. Naffah 2006-06-18 07:21:03 UTC
(In reply to comment #3)
> Please refer to the patch in:
> http://developer.classpath.org/pipermail/classpath-patches/2006-June/002696.html
> 
> In combination with the earlier patch, the requirements for this enhancement
> are met. Perhaps we would prefer providers split up into smaller jars? Anyway,
> the above patch should provide a good starting point.

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


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?




Comment 6 Vivek Lakshmanan 2006-06-19 21:18:04 UTC
(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


Comment 7 Raif S. Naffah 2006-06-20 20:57:51 UTC
(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?

Comment 8 Vivek Lakshmanan 2006-06-21 18:31:29 UTC
(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!
Comment 9 Raif S. Naffah 2006-06-22 10:15:22 UTC
(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.

Comment 10 Matt Wringe 2006-06-22 14:35:27 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > > ...
...
> > 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.
> 
...
> 
hmm, good idea. This will allow only specified applications to use the unsiged gnu-crypto.jars and will allow for java versions to be changed without having to update the new endorsed directory.

It can confirm that it also work on 1.5

If anybody has any other ideas about how to get around this issue, please comment.

Thanks,

Matt Wringe
Comment 11 Vivek Lakshmanan 2006-06-23 23:24:48 UTC
(In reply to comment #9)
> 
> 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.
Good idea! I just submitted a patch on classpath-patches: http://developer.classpath.org/pipermail/classpath-patches/2006-June/003017.html
which implements this. Please take a look when you get a chance.
Thanks!
Vivek
Comment 12 Raif S. Naffah 2006-06-24 00:46:39 UTC
(In reply to comment #11)
> (In reply to comment #9)
> > 
> > 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.
> Good idea! I just submitted a patch on classpath-patches:
> http://developer.classpath.org/pipermail/classpath-patches/2006-June/003017.html
> which implements this. Please take a look when you get a chance.

i'll have a closer look at it tonight and tomorrow but i quickly noticed a missing .cvsignore which should be added to the gnu.java.security folder and would contain "Configuration.java".
Comment 13 Raif S. Naffah 2006-06-24 14:37:10 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > 
> > > 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.
> > Good idea! I just submitted a patch on classpath-patches:
> > http://developer.classpath.org/pipermail/classpath-patches/2006-June/003017.html
> > which implements this. Please take a look when you get a chance.
> 
> i'll have a closer look at it tonight and tomorrow but i quickly noticed a
> missing .cvsignore which should be added to the gnu.java.security folder and
> would contain "Configuration.java".

except for the .cvsignore issue mentioned above, the patch looks fine.  please amend and commit!


Comment 14 Vivek Lakshmanan 2006-06-25 23:03:11 UTC
(In reply to comment #13)

> except for the .cvsignore issue mentioned above, the patch looks fine.  please
> amend and commit!
> 

Fixed and committed.
Vivek

Comment 15 Vivek Lakshmanan 2006-07-11 02:24:07 UTC
(In reply to comment #2)
> Some fixes to facilitate the separation of gnu-crypto into seperate jar has
> been posted for review:
> http://developer.classpath.org/pipermail/classpath-patches/2006-June/002635.html
> 
This patch has been updated to replace all references in crypto code to gnu.classpath.SystemProperties with AccessController.doPrivileged code:
http://developer.classpath.org/pipermail/classpath-patches/2006-July/003272.html 
I will commit this tomorrow, unless there are any objections...
Comment 16 Vivek Lakshmanan 2006-07-13 00:39:50 UTC
(In reply to comment #7)
> 
> > 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.
> 
Also, there seems to be a dependence on gnu.java.io.Base64InputStream in gnu.java.security.provider. Any suggestions on handling this?
Thanks,
Vivek

Comment 17 Raif S. Naffah 2006-07-14 05:53:53 UTC
(In reply to comment #16)
> (In reply to comment #7)
> > 
> > > 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.
> > 
> Also, there seems to be a dependence on gnu.java.io.Base64InputStream in
> gnu.java.security.provider. Any suggestions on handling this?

my Eclipse shows me:

1. the only class, in gnu.java.security.provider, which uses this class is X509CertificateFactory.

2. the static method in that class is not used by any class in the standalone candidate security packages.

one obvious --and simple-- option is to (only) duplicate the input-stream-related methods of that class in a (gnu.java.security.provider) package-private class.  keeping the same name means we only have to remove the import line from the dependant class (X509CertificateFactory).