To: Olaf Seibert <email@example.com>
From: Miles Nordin <carton@Ivy.NET>
Date: 04/21/1999 02:45:26
On Wed, 21 Apr 1999, Olaf Seibert wrote:
> b) Scrap it, and replace it with "foreign" code.
how about replacing it with a hacked version of KerberosIV or V that
called a shared lib to do all the crypto. The baseline lib installed by
'make build' would implement exportable crypto, plus whatever stubs were
needed to link. the Kerberos in the src tree plus the baseline lib would
be about like EBones.
for strong crypto, replace the stub lib with a binary-compatible shared
lib built from pkg, likely based on SSLeay or PGP or whatever's good these
days. a clever pkg could download all munitions source files from a
foreign master site. if patch-?? files need to contain dirty fragments,
perhaps these could be downloaded in an automated way at build time, too.
the part of pkgsrc checked into CVS would be exportable.
1. everything in CVS is exportable. US developers can maintain the
maximum imagineable fraction of code without violating ITAR.
right down to _file-by-file_ resolution with pkgsrc. it's
less code than they can maintain now, but let's be fair about this: if
you want exportable strong crypto, that's the price. this plan
minimizes the pain.
2. the multiple-sites hairyness is managed by the finely-tuned tools
we already have available for that purpose. no multiple anoncvs
servers to deal with by hand, just pkg master sites, which we already
know how to tolerate.
3. the difference between a US-only system and an exportable system
is a single shared library, not a bunch of stuff littered all
over the place, including _man pages_ even, like now.
4. one can legally build NetBSD + strong crypto anywhere in the
world merely by running 'make all install' in some directory.
an atomic step that any user can perform, rather than something
that stretches its devious invasive fingers into the whole build
process and befuddles the 'build' target.
5. the French (is crypto still illegal there?) get an EBONES-ish
system for free out of the deal. the difference between a crypto
and non-crypto system is _just crypto_. whatever behaviour,
w.r.t. trying to fetch TGT's on login u.s.w., is consistent,
well-defined, sane...on all systems.
1. NetBSD Kerberos would be unlikely to interoperate with standard
2. It creates a version-sync problem between src and pkgsrc. minimum
one would probably need a crypto-release and crypto-current pkg.
we don't have any other pkgsrc-src dependencies this rigid.
but what's worse: checking out two trees on one server, or checking
out from two different servers!
3. you have to be real careful about commit's. but let's be fair:
(a) you _always_ have to be careful about commit's, yes?
(b) the accidental-export fear is now a problem for the people with
commit access, not those running sup or anoncvs. this is
a good thing. the whole point was to establish control.
with this plan, you have it. obviously _someone_ needs to be
Miles Nordin / 1-888-857-2723
555 Bryant Street #182 / Palo Alto, CA 94301-1700