[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: merging GNU Crypto and Jessie

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 be
honest, I'm not sure what specific algorithms this means. It's possible
that 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, or just the algorithms?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]