Re: USA crypto rules and libssl-dependent packages
On Fri, May 11, 2001 at 09:03:48PM -0400, Brian Ristuccia 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.
I don't understand this (but am willing to believe it). Please elaborate, if
you would.
> 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.
What if they are living in France, where private use of cryptography is
illegal? They might be using non-US to get things that are excluded from the
US mirrors due to patent rather than cryptography reasons, and so they might
still find use for a non-crypto version of my package, which they would be
able to get from non-US/main rather than main (for the reason stated in your
quoted bit above) if I distribute such a thing.
> > > 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).
Since the only difference here is a few lines in the makefile, I could easily
generate a crypto and a non-crypto version from the same source packge with
some simple fileutils magic in debian/rules. BTW can anyone on -mentors explain
how I set up a debian/rules file that generates multiple binary packages?
Also, this makes me realize, the following entry was listed in the SourceForge
release notes for version 0.4.3 (an old release) of my package:
--
This version adds a bit of "security." Rather than storeing the user's password
in plain text in a world readable config file, it saves it scrambled (though
easily decryptable with the algorithm included in the source) in a file which
is not world readable.
--
This doesn't seem like real strong cryptography, and it may not qualify as
any cryptography at all, just simple encoding (as opposed to encrypting). Is
this legal to use in countries such as France? Also, is France's prohibition on
cryptography limited to strong cryptography or not? If this would count as
crypto then even the non-ssl version would have crypto. (There is no apparent
way to disable compilation of this feature without hacking of the source -
which could be done with sufficient justification, I guess.)
- Jimmy Kaplowitz
jimmy@kaplowitz.org
Reply to: