|
From: | Casey Marshall |
Subject: | Re: RFC: merging GNU Crypto and Jessie |
Date: | Thu, 8 Dec 2005 20:07:10 -0800 |
On Dec 8, 2005, at 11:25 AM, Anthony Green wrote:
On Mon, 2005-12-05 at 23:42 -0800, Casey Marshall wrote:A few of us have been throwing around the idea of merging GNU Crypto and Jessie into GNU Classpath, so Classpath will have full support for crypto and SSL "out of the box." We've proposed this before, and I think this idea was mostly approved by the group, but no-one ever got around to doing it.My only concern is there be some trivial mechanism to generate a US export-friendly version GNU Classpath, like.. $ configure --disable-munitions
Good point. We should have a switch for this in configure. Probably adding the appropriate lines to standard.omit will do it?
Also, J2SE has the ExemptionMechanism class, which is currently not much more than a stub in Classpath. I mean, it's trivially easy to get around this restriction with free software -- you just change the source -- but including a real implementation of that class may be enough to satisfy these restrictions.
I wouldn't use --disable-munitions, though. The US Government spooks believe crypto is a munition, but I don't.
My understanding is that the US government has made it simpler to distribute FOSS crypto code in recent years, but I have a situation where I actually need to strip all export controlled crypto. To behonest, I'm not sure what specific algorithms this means. It's possiblethat Classpath already contains some.
Yes. RSA is export-controlled for key sizes larger than 40 bits, IIRC.
In any case, it would be nice if the configury and build process could automatically handle the absence of crypto algorithms.
Should this disable compiling the standard crypto library bits, too (javax.crypto and javax.net.ssl), or just the algorithms?
Thanks.
[Prev in Thread] | Current Thread | [Next in Thread] |