[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: USA crypto rules and libssl-dependent packages



Jimmy Kaplowitz <jimmy@kaplowitz.org> writes:

> Choice 2: Use the same source package for both althea and
> althea-ssl. [...] However, since even the non-crypto version would
> be in non-US, anyone in a crypto-restricted country who gets their
> .debs from CD-ROMs would probably not get any copy of althea, since
> they would not get the Binary 1 non-US version.

I'm not sure of the fact that people in Russia, China, et al have no
access to non-US CDs (maybe their governments even like the title
better <g>). Does anybody have concrete knowledge in this regard?

> 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.

That's against policy (IMHO, it's not explicit). Here are the relevant
paragraphs:

    In addition, the packages in main

    * must not require a package outside of main for compilation or
      execution (thus, the package must not declare a "Depends",
      "Recommends", or "Build-Depends" relationship on a non-main
      package), [...]

Since policy talks about "main" and "non-US/main" as separate
entities, I do not think that "main" includes non-US in the above
sentence. Later:

    [...] A package containing a program with an interface to a
    cryptographic program or a program that's dynamically linked
    against a cryptographic library should not be distributed via
    the non-US server if it is capable of running without the
    cryptographic library or program.

Note the /if/. See also bug #95146 for a similar case with postgresql.

> 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.

Since libssl is still in a non-US section, they can simply omit that
from their configuration to never make this mistake.

-- 
Robbe

Attachment: signature.ng
Description: PGP signature


Reply to: