Subject: Background on cryptosrc-intl proposal
To: None <email@example.com>
From: Michael C. Richardson <firstname.lastname@example.org>
Date: 06/22/1999 20:45:50
I'd like to start a discussion on what to include in the initial
cryptosrc-intl tree. This serves as background. It has been discussed
by netbsd-developers for some time.
$Id: netbsd-intl-plan,v 1.4 1999/06/22 23:38:44 mcr Exp mcr $
NetBSD's source tree currently includes a subtree called "domestic"
which contains code that can not leave the United States due to
Cryptographic export restrictions.
People not resident in the United States currently have no standard
cryptographic facilities as part of their tree. While there is plenty
of available code available outside of the US, it is not well
integrated into the system, and so is hard to use, and hard to
count upon. As the NetBSD source tree is currently hosted in
the United States, it is not currently possible for non-US citizens
to usefully contribute cryptographic code to the NetBSD tree
as once it enters the US, it may not leave again.
The NetBSD Foundation has secured a machine with disk space
and sufficient internet bandwidth to function as a non-US CVS
server. This is cvs.fi.netbsd.org. The machine was provided by
SSH Communications Security Oy, and the bandwidth by HUT
(Helsinki University of Technology). Finland has rather
liberal export rules on cryptography, so while US citizens
(and people resident in the US) are still forbidden to
contribute cryptographic to this repository, then can at least
import it, and the rest of us can freely contribute code.
All of the non-crypgraphic parts of the NetBSD CVS repository
code will be mirrored and/or moved to cvs.fi.netbsd.org. The
details of this are not covered in this document.
A new subtree of /usr/src will be created. It will be named
| "crypto-intl". In the new source tree organization, it will
| live in /cvsroot/cryptosrc-intl/crypto-intl.
A new subtree is needed as citizens/residents of countries with
export restrictions will not be able to contribute code
to this part of the tree. The distinction will help them avoid
breaking their own (misguided) laws.
Some comments about the name: while the opposite of "domestic"
is "export", typically the "export" version of a US program is
the version without cryptography. We are not trying to do
that. Rather we are making a non-US version that has
cryptography. Intl is short for "international"
| It has been suggested that "intl" along may get confused with i18n
| efforts to make NetBSD happy with multilingual character sets. Thus
| the name change to "crypto-intl"
| Subdirectories of "crypt-intl" will resemble those of domestic (I'm
told. I've never officially seen it ;-} ), or "gnu", i.e. there will be:
| /usr/src/crypto-intl/lib - support libraries
| /usr/src/crypto-intl/bin - programs for /bin
| /usr/src/crypto-intl/usr.bin - programs for /usr/bin
| /usr/src/crypto-intl/sbin - programs for /sbin
| /usr/src/crypto-intl/usr.sbin - programs for /usr/sbin
| /usr/src/crypto-intl/sys - kernel code
| /usr/src/crypto-intl/dist - original archives
| /usr/src/crypto-intl/libexec - daemons
Where reasonable, the Makefile files will use the "reach-over"
technique into the dist area where original packages source
trees will be kept. E.g:
/usr/src/crypto-intl/lib/libdes/Makefile might grab code from
| The kernel "crypto-intl/sys" area will be a shadow of /usr/src/sys.
| There will a /usr/src/crypto-intl/sys/conf/files that will include
/usr/src/sys/conf/files etc. This will allow kernels to be
build/configured/etc. that contain cryptography, but without
duplicating or polluting any of /usr/src/sys which must remain
exportable from the US. Modifications to config(9) may be required to
deal with additional paths, or possible additional makefile
sections. At this time, it is believed that no additional features
will be needed.
What to include, where to put it
Quite a large number of cryptographic programs may be better
suited for pkgsrc inclusion. Apache-SSL comes to mind here.
There are however, several categories of programs that will
need to go into crypto-intl:
1. anything intended to go into the kernel:
-cryptographic signing of user binaries/lkms
-public key based capability based extensions (a la KeyOS)
-cryptographic file systems (including network file systems
i.e. AFS-like stuff)
-secure network booting code
2. support programs for above
3. base libraries/headers that we wish to distribute to make crypto
ubiquitous: i.e. RSA, DSS, DH, CAST, 3DES
4. code that enhanced from code we maintain (i.e. Kerberized
5. original code from the NetBSD project
#4 implies that we would like to have Kerberos version 4 and
Kerberos version 5 included. It is hoped that the Heimdal
project will eventually provide this base. We can
argue about whether or not we should just leave this
We will start using cvs.fi.netbsd.org as soon as this proposal
The 1.5-current snapshots will start to include a "crypto-intl"
The "secr" package would be renamed "domestic" or "domt".
1.5 might ship with just the crypto-intl package for distributions
that are created outside of the US. This is open to debate. We may
prefer to continue leaving crypto an optional part.
Additional minor items
1. create a new list "tech-crypto"
2. while it isn't that cool, you can check out "src" from
cvs.netbsd.org and then checkout "src/crypto-intl" from
cvs.fi.netbsd.org. You need to be a bit careful about not running
"cvs update" from the toplevel with CVS versions lower than
1.10. 1.10 can cope with parts of the tree being on different servers.
3. we need to make sure that all ports have a non-US builder to build
the crypto-intl area. It isn't enough to have a non-US machine, but
the person typing "make" must not be a US citizen or a US resident.
Herb's lab is in Calgary, so machines should be in the right place.