crypto policy redux
In packaging Kerberos 5, I've come up against a tricky packaging
problem. The Kerberos 5 sources contain a number of smaller utility
libraries, such as com_err, libss, and libdyn, that contain no
cryptographic source code and are freely redistributable.
Although these libraries are used and provided by a number of other
Debian packages (notably e2fsprogs), they currently exist in their
most mature form in the Kerberos sources. I've spent the last couple
of days patching these other programs so that they can use external
versions of these libraries, and expect the patches to eventually be
picked up by the upstream sources.
The upstream sources have also agreed to try to converge their uses of
these small libraries to a single implementation, but I expect that it
will be some time before this is accomplished. I also hope to be able
to convince them to factor out these libraries into separate packages,
but have not yet managed to do so.
The policy question:
[ Please note that when I say "upload" in the following, I do not mean
that I will actually be uploading cryptographic source code or
executables --- I use the word solely as convenient shorthand. ]
How should I handle the generation of free packages from
cryptographically restricted sources? As I see it, there are two
options:
A: Upload the Kerberos source to non-US only, and upload the
non-crypto packages to the main distribution without source.
(After all, the source really is freely available, just not
from the same FTP site).
B: Duplicate the Kerberos source into two source packages, one of
which builds all the packages, both crypto and non-crypto,
and the other of which has all cryptographic code removed.
Upload the former to the main distribution and the latter to the
non-US site.
Arguments for "A" are that it is the most faithful representation of
the original sources; and that having two copies of the same source
package is an invitation for version skew and confusion. Choosing
option "A" also implies that to some degree crypto-restricted packages
are a part of the main distribution in a way that copyright-restricted
packages are not, which may be a political stance we wish to take.
Arguments for "B" are that we may consider it important to always be
able to generate all the binaries in the main distribution from
sources also in the main distribution. One could also argue that "B"
reflects the way the sources should be packaged upstream in the first
place, and so all we're doing is repairing an upstream design flaw.
At the moment, I tend to prefer "B", but I'd be interested in hearing
other people's opinions. If we do choose "B", which of the following
splits should we choose?
a: Full source package in non-US; full source package with
cryptographic routines removed in main distribution.
b: Full source package in non-US; utility libraries only in main
distribution.
c: Full source package minus utility libraries in non-US; utility
libraries only in main distribution.
Here (c) best reflects my view of how the upstream sources "ought to
be," but I believe we should choose (a) because it requires the least
radical modification of the upstream sources.
Opinions?
Reply to: