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
brian@ristuccia.com
bristucc@cs.uml.edu
Reply to: