Re: USA crypto rules and libssl-dependent packages
On Thu, May 10, 2001 at 07:27:44PM -0400, Jimmy Kaplowitz wrote: > Hi. I am a novice Debian package maintainer, in the queue for becoming an > official developer. I am maintaining a package called althea, which is an > IMAP email client for GTK+. They have recently added support for SSL through > linking to libssl (from OpenSSL). This is configurable based on the values > of a couple variables in the Makefile. I have a couple of questions: > > 1) I live in the US. Therefore, do I have to send a BXA notification to the > government (I believe license exception TSU is applicable - correct me if I'm > wrong)? You may. Since it's easy, you probablys hould. > Also, do I have to do their thing that they mention on their website > about sending a message to the ENC Classification Review Coordinator (or, > something like that) in addition to [EMAIL PROTECTED], and if so, how do I > do that? I think the email to [EMAIL PROTECTED] is sufficient. > Also, is a BXA notification form sufficient to export binary .debs > linked with libssl? Yes. > Would anyone be able to export them, including other US > mirror sites, so long as I provide an export of the same stuff that I notify > the BXA about? Probably. It's my theory that the software is no longer export restricted once you make the BXA notification. Thus Debian's requirement that export restricted software get uploaded to non-us doesn't apply. Indeed, this is how Netscape with strong crypto got uploaded to non-free instead of non-us/non-free. There's currently an inquiry going on that will determine if Debian's policy can be updated to clearly reflect the new regulations. > > 2) Do the binary .debs go in non-US? Yes. Policy currently requires it. > What about the Debian source files? Same. > If I > make additional non-ssl .debs from the same source, would they be in > non-US or not? Yes, but only if the source actually contains crypto. Source or binary, policy currently requires export restricted software to be uploaded to non-us. > [other stuff omitted] Good luck :) -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] pgppX4U1CXDUq.pgp Description: PGP signature
Re: lame (again!)
On Fri, May 11, 2001 at 10:14:22PM +0200, Marcelo E. Magallon wrote: > >> Viral <[EMAIL PROTECTED]> writes: > > > I would like clarify the reason for lame not being included in the debian > > archives, not even non-US. > > http://www.debian.org/devel/wnpp/unable-to-package > > IIRC your questions are addressed there. > Lame is already included in the Debian archives in libmp3lame_audioenc.so.0 in libavifile in debian/main. It's in shared library form, but appears to be a fully functional mpeg-1 layer 3 encoder and not just a wrapper that invokes a lame binary the user already has on their system. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Fri, May 11, 2001 at 08:28:12PM -0400, Jimmy Kaplowitz wrote: > > > > > > > 2) Do the binary .debs go in non-US? > > > > Yes. Policy currently requires it. > > OK, I understand that this is a quirk of Debian policy, and not US law. > It wouldn't make sense for .deb's to go in a place different than their source code. Otherwise, you wouldn't be able to rebuild from source without specifying additional places to get source tarballs and diffs from. > > > What about the Debian source files? > > > > Same. > > I guess this makes sense, since there would need to be a Build-Depends on > libssl-dev. (Am I right about that?) Yes. > > > > If I > > > make additional non-ssl .debs from the same source, would they be in > > > non-US or not? > > > > Yes, but only if the source actually contains crypto. Source or binary, > > policy currently requires export restricted software to be uploaded to > > non-us. > > Well, I don't intend to redistribute libssl, in my source or binary .debs, > just dynamically link to them at compile and then run time. So do the non-ssl > .debs go in the non-US/main or main? > There are legitimate reasons why non-crypto .deb's might need to go in non-US/main. For example if the source and diffs must go in non-us, you can't put the .deb's built from them anywhere else. In this case, it's probably silly to even bother distributing them since anyone who was using non-US could just use the ssl versions. > > Good luck :) > > Thank you! I may also download the source of some package that comes in ssl > and non-ssl flavors and see how they do it. Can you suggest one? I'm thinking > of lynx, myself. > lynx has seperate and distinct sources for the crypto and non-crypto versions. Based on size alone, I suspect the non-ssl version has all the crypto stuff ripped out (or the ssl version has it patched in). -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Sat, May 12, 2001 at 09:52:48PM -0400, Jimmy Kaplowitz wrote: > Thank you all very much for replying. I am torn between three avenues that I > am > considering taking. > > Choice 3: Just change the main althea package to include ssl support, and add > to the package description and README.Debian notification to that effect, with > instructions on how to get a non-SSL version built. This would be simpler for > me, but less convenient for users, who would have to build a non-SSL version > for each new release. To alleviate this difficulty, I could offer to build a > non-SSL package (a la Choice 1 or 2) if I got enough demand for it. Also, > though, any users who already have the non-crypto version of althea installed > and who do a blind dist-upgrade will install libssl by mistake, which could be > illegal in some locales. > > I do intend to send BXA notification to enable me to upload to non-US despite > my residence within the US. > > What do you all think? What should I do? > Choice 3 is best. People who live in countries where the use of cryptography is restricted are probably subject to being arbitrarily jailed or murdered by their state's government anyway. Going out of your way to provide crippled crypto-neutered versions of things only validates such sillyness. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Sat, May 12, 2001 at 11:12:34PM -0400, Jimmy Kaplowitz wrote: > On Sat, May 12, 2001 at 10:10:30PM -0400, Brian Ristuccia wrote: > > > > Choice 3 is best. People who live in countries where the use of cryptography > > is restricted are probably subject to being arbitrarily jailed or murdered > > by their state's government anyway. Going out of your way to provide > > crippled crypto-neutered versions of things only validates such sillyness. > > > What in the world do you mean? I don't think France has arbitrary atrocities > by the government like you described, and I'm not sure if this is still true, > but at least until recently crypto was prohibited there. > France's restrictions on crypto use went away back in 1999. Have a look at http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm and http://cwis.kub.nl/~frw/people/koops/cls-dom.gif for information on places with domestic crypto restrictions. Most of these places don't have spectacular human rights records. China, for example, uses tanks against its own civilians and keeps prisoners of conscience. In a number of the old Soviet states, people with unpopular political views used to disappear in the middle of the night, never to be seen again. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Thu, May 10, 2001 at 07:27:44PM -0400, Jimmy Kaplowitz wrote: > Hi. I am a novice Debian package maintainer, in the queue for becoming an > official developer. I am maintaining a package called althea, which is an > IMAP email client for GTK+. They have recently added support for SSL through > linking to libssl (from OpenSSL). This is configurable based on the values > of a couple variables in the Makefile. I have a couple of questions: > > 1) I live in the US. Therefore, do I have to send a BXA notification to the > government (I believe license exception TSU is applicable - correct me if I'm > wrong)? You may. Since it's easy, you probablys hould. > Also, do I have to do their thing that they mention on their website > about sending a message to the ENC Classification Review Coordinator (or, > something like that) in addition to [EMAIL PROTECTED], and if so, how do I > do that? I think the email to [EMAIL PROTECTED] is sufficient. > Also, is a BXA notification form sufficient to export binary .debs > linked with libssl? Yes. > Would anyone be able to export them, including other US > mirror sites, so long as I provide an export of the same stuff that I notify > the BXA about? Probably. It's my theory that the software is no longer export restricted once you make the BXA notification. Thus Debian's requirement that export restricted software get uploaded to non-us doesn't apply. Indeed, this is how Netscape with strong crypto got uploaded to non-free instead of non-us/non-free. There's currently an inquiry going on that will determine if Debian's policy can be updated to clearly reflect the new regulations. > > 2) Do the binary .debs go in non-US? Yes. Policy currently requires it. > What about the Debian source files? Same. > If I > make additional non-ssl .debs from the same source, would they be in > non-US or not? Yes, but only if the source actually contains crypto. Source or binary, policy currently requires export restricted software to be uploaded to non-us. > [other stuff omitted] Good luck :) -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] PGP signature
Re: lame (again!)
On Fri, May 11, 2001 at 10:14:22PM +0200, Marcelo E. Magallon wrote: > >> Viral <[EMAIL PROTECTED]> writes: > > > I would like clarify the reason for lame not being included in the debian > > archives, not even non-US. > > http://www.debian.org/devel/wnpp/unable-to-package > > IIRC your questions are addressed there. > Lame is already included in the Debian archives in libmp3lame_audioenc.so.0 in libavifile in debian/main. It's in shared library form, but appears to be a fully functional mpeg-1 layer 3 encoder and not just a wrapper that invokes a lame binary the user already has on their system. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Fri, May 11, 2001 at 08:28:12PM -0400, Jimmy Kaplowitz wrote: > > > > > > > 2) Do the binary .debs go in non-US? > > > > Yes. Policy currently requires it. > > OK, I understand that this is a quirk of Debian policy, and not US law. > It wouldn't make sense for .deb's to go in a place different than their source code. Otherwise, you wouldn't be able to rebuild from source without specifying additional places to get source tarballs and diffs from. > > > What about the Debian source files? > > > > Same. > > I guess this makes sense, since there would need to be a Build-Depends on > libssl-dev. (Am I right about that?) Yes. > > > > If I > > > make additional non-ssl .debs from the same source, would they be in > > > non-US or not? > > > > Yes, but only if the source actually contains crypto. Source or binary, > > policy currently requires export restricted software to be uploaded to > > non-us. > > Well, I don't intend to redistribute libssl, in my source or binary .debs, > just dynamically link to them at compile and then run time. So do the non-ssl > .debs go in the non-US/main or main? > There are legitimate reasons why non-crypto .deb's might need to go in non-US/main. For example if the source and diffs must go in non-us, you can't put the .deb's built from them anywhere else. In this case, it's probably silly to even bother distributing them since anyone who was using non-US could just use the ssl versions. > > Good luck :) > > Thank you! I may also download the source of some package that comes in ssl > and non-ssl flavors and see how they do it. Can you suggest one? I'm thinking > of lynx, myself. > lynx has seperate and distinct sources for the crypto and non-crypto versions. Based on size alone, I suspect the non-ssl version has all the crypto stuff ripped out (or the ssl version has it patched in). -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Sat, May 12, 2001 at 09:52:48PM -0400, Jimmy Kaplowitz wrote: > Thank you all very much for replying. I am torn between three avenues that I am > considering taking. > > Choice 3: Just change the main althea package to include ssl support, and add > to the package description and README.Debian notification to that effect, with > instructions on how to get a non-SSL version built. This would be simpler for > me, but less convenient for users, who would have to build a non-SSL version > for each new release. To alleviate this difficulty, I could offer to build a > non-SSL package (a la Choice 1 or 2) if I got enough demand for it. Also, > though, any users who already have the non-crypto version of althea installed > and who do a blind dist-upgrade will install libssl by mistake, which could be > illegal in some locales. > > I do intend to send BXA notification to enable me to upload to non-US despite > my residence within the US. > > What do you all think? What should I do? > Choice 3 is best. People who live in countries where the use of cryptography is restricted are probably subject to being arbitrarily jailed or murdered by their state's government anyway. Going out of your way to provide crippled crypto-neutered versions of things only validates such sillyness. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: USA crypto rules and libssl-dependent packages
On Sat, May 12, 2001 at 11:12:34PM -0400, Jimmy Kaplowitz wrote: > On Sat, May 12, 2001 at 10:10:30PM -0400, Brian Ristuccia wrote: > > > > Choice 3 is best. People who live in countries where the use of cryptography > > is restricted are probably subject to being arbitrarily jailed or murdered > > by their state's government anyway. Going out of your way to provide > > crippled crypto-neutered versions of things only validates such sillyness. > > > What in the world do you mean? I don't think France has arbitrary atrocities > by the government like you described, and I'm not sure if this is still true, > but at least until recently crypto was prohibited there. > France's restrictions on crypto use went away back in 1999. Have a look at http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm and http://cwis.kub.nl/~frw/people/koops/cls-dom.gif for information on places with domestic crypto restrictions. Most of these places don't have spectacular human rights records. China, for example, uses tanks against its own civilians and keeps prisoners of conscience. In a number of the old Soviet states, people with unpopular political views used to disappear in the middle of the night, never to be seen again. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
