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
Re: RFC: merging GNU Crypto and Jessie
Hi Casey, On Mon, 2005-12-05 at 23:42 -0800, Casey Marshall wrote: I propose that we - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in GNU Crypto, and merge the current CVS sources into Classpath (not under external/). We then put GNU Crypto into a kind of stasis mode, and continue to develop these sources in Classpath. - Rename the root package 'org.metastatic.jessie' to 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then, I'll stop developing that branch on its own. We can then also merge other parts of GNU Crypto to projects where they make sense; its testsuite can go into Mauve (it was written to use (a possibly old version of) Mauve's own test harness classes), and the various tools can go into cp-tools. I think most Classpath hackers think this is a good idea Yeah I believe this is a good idea. I know GNU Crypto doesn't have any external dependencies. Jessie has an external dependency on JZlib which is in principle OK, but having multiple zip implementations in the tree is not perfect. Do you have an idea whether it would be possible to hook Jessie to the (internal) util.zip implementation we have? One complication is that a couple of projects based on GNU Classpath have another util.zip implementation based on zlib. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RFC: merging GNU Crypto and Jessie
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 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. In any case, it would be nice if the configury and build process could automatically handle the absence of crypto algorithms. Thanks, AG ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RFC: merging GNU Crypto and Jessie
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 javax.net.ssl), or just the algorithms? Thanks. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RFC: merging GNU Crypto and Jessie
On Dec 8, 2005, at 10:32 AM, Mark Wielaard wrote: Hi Casey, On Mon, 2005-12-05 at 23:42 -0800, Casey Marshall wrote: I propose that we - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in GNU Crypto, and merge the current CVS sources into Classpath (not under external/). We then put GNU Crypto into a kind of stasis mode, and continue to develop these sources in Classpath. - Rename the root package 'org.metastatic.jessie' to 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then, I'll stop developing that branch on its own. We can then also merge other parts of GNU Crypto to projects where they make sense; its testsuite can go into Mauve (it was written to use (a possibly old version of) Mauve's own test harness classes), and the various tools can go into cp-tools. I think most Classpath hackers think this is a good idea Yeah I believe this is a good idea. I know GNU Crypto doesn't have any external dependencies. Jessie has an external dependency on JZlib which is in principle OK, but having multiple zip implementations in the tree is not perfect. Do you have an idea whether it would be possible to hook Jessie to the (internal) util.zip implementation we have? One complication is that a couple of projects based on GNU Classpath have another util.zip implementation based on zlib. Yeah, it's simple to remove the dependency on jzlib. In fact, there is already an alternative crypto engine in jessie that uses javax.crypto/java.util.zip instead of gnu.crypto/jzlib. Just removing the latter version should suffice. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RFC: merging GNU Crypto and Jessie
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. I'd like to propose again that we do this. I'll try to get to this myself, but if I can't get this done, we'll at least have a plan of action. I propose that we - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in GNU Crypto, and merge the current CVS sources into Classpath (not under external/). We then put GNU Crypto into a kind of stasis mode, and continue to develop these sources in Classpath. - Rename the root package 'org.metastatic.jessie' to 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then, I'll stop developing that branch on its own. We can then also merge other parts of GNU Crypto to projects where they make sense; its testsuite can go into Mauve (it was written to use (a possibly old version of) Mauve's own test harness classes), and the various tools can go into cp-tools. I think most Classpath hackers think this is a good idea; I'm sending this mail out to the individual project lists to see if there are any objections from users of either package. To be clear, GNU Crypto won't go away, while Jessie will. GNU Crypto MAY continue to be developed, but not by me (and if history is a precedent, then neither by anyone else). If I'm not able to put this patch together, I will answer anyone's questions about how to proceed, if we get a volunteer. Awesome! I believe fitzsim and me are making simultaneous saltos[1] of joy at different ends of the planet at the moment. :) cheers, dalibor topic [1] figuratively speaking. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RFC: merging GNU Crypto and Jessie
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. I'd like to propose again that we do this. I'll try to get to this myself, but if I can't get this done, we'll at least have a plan of action. I propose that we That would be really great! Maybe i can help in some way, although i don't have the time to merge it on myself. TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
