Re: [GNU Crypto] Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
hello Anthony, On Monday 12 December 2005 20:52, Anthony Green wrote: On Mon, 2005-12-12 at 20:48 +1100, Raif S. Naffah wrote: would adding a second Provider --that supplies the strong stuff; i.e. ciphers, modes, padding, etc..-- living in its own package sub-directory/hierarchy and eventually (when the segmentation of Classpath into multiple jars occur) be packaged in its own jar help solve your problem? Yes, that would be nice. looking at the current Classpath package structure and classes, i see that an implementation of a Cipher using RSA is already included. those are normally part of the javax.crypto strain. do you strip those out when you package your export-controlled applications? cheers; rsn pgpBcUaqmp7QO.pgp Description: PGP signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [GNU Crypto] Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
On Mon, 2005-12-12 at 20:48 +1100, Raif S. Naffah wrote: would adding a second Provider --that supplies the strong stuff; i.e. ciphers, modes, padding, etc..-- living in its own package sub-directory/hierarchy and eventually (when the segmentation of Classpath into multiple jars occur) be packaged in its own jar help solve your problem? Yes, that would be nice. AG ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [GNU Crypto] Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
On Monday 12 December 2005 01:45, Anthony Green wrote: On Sun, 2005-12-11 at 15:19 +0100, Mark Wielaard wrote: If there are situations where you are not able to (re)distribute the GNU Classpath source code and/or follow the the BIS/ENC notification procedures as done by the various GNU/Linux distros to distribute binary derivatives of GNU Classpath as Free Software works then please let us know. I don't think my situation is relevant to public Linux distros. I'm told the rules are different when you want to make a private distribution of FOSS crypto code (ie. not easily found on a public web/ftp site). In my specific case, it's easier just to remove the problematic code completely. would adding a second Provider --that supplies the strong stuff; i.e. ciphers, modes, padding, etc..-- living in its own package sub-directory/hierarchy and eventually (when the segmentation of Classpath into multiple jars occur) be packaged in its own jar help solve your problem? cheers; rsn pgpwTIeTvE2l2.pgp Description: PGP signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
Hi, On Thu, 2005-12-08 at 20:07 -0800, Casey Marshall wrote: On Dec 8, 2005, at 11:25 AM, Anthony Green wrote: 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 javax.net.ssl), or just the algorithms? As far as I know even the hooks fall under this. Although I am not against having some configure options to put parts of the core library into standards.omit I don't think it is really needed. When the first parts of GNU Crypto was merged into GNU Classpath (and indirectly into GCC and other projects) FSF legal made sure that all FSF distributed GNU software would be able to be distributed (as source) from ftp.gnu.org from mirrors. See the statement on savannah: https://savannah.gnu.org/faq/?admin=group_id=5802question=Savannah_-_Is_there_any_restriction_on_cryptographic_software.txt Similar notices have been placed on ftp.gnu.org and other distribution sites (ftp://ftp.gnu.org/CRYPTO.README). We really don't need more then that as long as we distribute GNU Classpath as Free Software. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
Hi Anthony, On Sun, 2005-12-11 at 03:47 -0800, Anthony Green wrote: You're missing my point, which is that _I_ have a requirement to redistribute GNU Classpath with no export-restricted software. What's good enough for the FSF is not good enough for me. It would nice if there was a convenient way of doing this. Sure, and please do propose a patch to help you if you are willing to maintain that. But beware that you probably need guidance from a legal adviser to make sure you strip out and distribute only those parts not covered by the BXA. All I was saying is that it isn't a necessity for GNU Classpath as a project, or people redistributing GNU Classpath as Free Software. And binary derivatives from distributions and other projects already have to handle this if they have the misfortune to be distributed from inside the USA. See for example the Debian crypto guidelines [1] on how to deal with the the BIS/ENC notification procedures (I assume Fedora has similar guidelines). So, the situation doesn't change from when we first started distributing crypto hooks and algorithms with GNU Classpath [2]. Cheers, Mark [1] http://www.debian.org/legal/cryptoinmain [2] http://lists.gnu.org/archive/html/classpath/2004-08/msg00076.html signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
On Sun, 2005-12-11 at 12:40 +0100, Mark Wielaard wrote: As far as I know even the hooks fall under this. Although I am not against having some configure options to put parts of the core library into standards.omit I don't think it is really needed. When the first parts of GNU Crypto was merged into GNU Classpath (and indirectly into GCC and other projects) FSF legal made sure that all FSF distributed GNU software would be able to be distributed (as source) from ftp.gnu.org from mirrors. See the statement on savannah: https://savannah.gnu.org/faq/?admin=group_id=5802question=Savannah_-_Is_there_any_restriction_on_cryptographic_software.txt Similar notices have been placed on ftp.gnu.org and other distribution sites (ftp://ftp.gnu.org/CRYPTO.README). We really don't need more then that as long as we distribute GNU Classpath as Free Software. You're missing my point, which is that _I_ have a requirement to redistribute GNU Classpath with no export-restricted software. What's good enough for the FSF is not good enough for me. It would nice if there was a convenient way of doing this. Merging GNU Crypto into GNU Classpath without regards to this issue is moving in a bad direction for me (and perhaps others). AG ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
On Sun, 2005-12-11 at 13:50 +0100, Mark Wielaard wrote: All I was saying is that it isn't a necessity for GNU Classpath as a project, or people redistributing GNU Classpath as Free Software. I'm being told that there are situations where this second part is not true, which is why I need to remove the export controlled code. AG ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
Hi Anthony, On Sun, 2005-12-11 at 05:38 -0800, Anthony Green wrote: On Sun, 2005-12-11 at 13:50 +0100, Mark Wielaard wrote: All I was saying is that it isn't a necessity for GNU Classpath as a project, or people redistributing GNU Classpath as Free Software. I'm being told that there are situations where this second part is not true, which is why I need to remove the export controlled code. If there are situations where you are not able to (re)distribute the GNU Classpath source code and/or follow the the BIS/ENC notification procedures as done by the various GNU/Linux distros to distribute binary derivatives of GNU Classpath as Free Software works then please let us know. And follow up with some more concrete information about these situations. I am happy to discuss this with FSF legal and see if there are procedures to help in your situation. How are these situations different from distributing GPG, GCC, Mozilla, OpenSSH, etc? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
On Sun, 2005-12-11 at 15:19 +0100, Mark Wielaard wrote: If there are situations where you are not able to (re)distribute the GNU Classpath source code and/or follow the the BIS/ENC notification procedures as done by the various GNU/Linux distros to distribute binary derivatives of GNU Classpath as Free Software works then please let us know. I don't think my situation is relevant to public Linux distros. I'm told the rules are different when you want to make a private distribution of FOSS crypto code (ie. not easily found on a public web/ftp site). In my specific case, it's easier just to remove the problematic code completely. AG ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
