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.

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

Disadvantages
 1. NetBSD Kerberos would be unlikely to interoperate with standard
    versions.
 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
        responsible.

-- 
Miles Nordin / 1-888-857-2723
555 Bryant Street #182 / Palo Alto, CA 94301-1700