ghudson at MIT.EDU
Wed Jun 10 12:40:31 EDT 2009
A discussion of directory naming (a topic which I know is more
interesting to me than many other people):
The names "common-mit", "common-openssl", and "krb" came from me, and
I'm not fond of any of them; I've been trying to think of better ones.
A little more background on the distinction we're trying to draw:
libk5crypto contains three basic kinds of stuff:
1. Generic, externally defined crypto algorithms like AES
2. Kerberos-specific algorithms like CF2
3. Kerberos-specific bookkeeping routines defining the API (enctypes
The idea is to make category 1 pluggable at compile time, recognizing
that any particular back end (OpenSSL, NSS, BSafe, PKCS11) may only
provide a subset of the algorithms. So "krb" is my dummy name to hold
the Kerberos-specific stuff (category 2 and 3) and "common-mit" and
"common-openssl" are my dummy names for the direct implementations of
(1) and the indirect implementations via OpenSSL.
I don't like the prefix "common" because it is often used to mean
"common across all architectures" (or across all something else), and
what it means here is something else. I don't like the name
"common-mit" in particular because it suggests that MIT is the original
author of the code contained therein, which is not true in some (most?)
cases. I don't like the name "krb" on principal (the name of the
project is usually meaningless as a subdirectory name within that
project) but it's the most reasonable.
After a few more minutes of thought, I tentatively like the names
"generic-direct", "generic-openssl", and "krb" better than the set of
names I initially picked.
The idea, incidentally, is for the build to descend into all
subdirectories, and inside each subdirectory to pick which objects to
build based on configure-time options. For example, a build with the
OpenSSL back end would build all objects inside generic-openssl, and
some of the objects inside generic-direct corresponding to the
algorithms not implemented by OpenSSL.
(I'm aware that Sam thinks that NSS is a better initial back end than
OpenSSL. I continued using OpenSSL in my discussion above for the sake
of example, but that doesn't mean I have any particular opinion on that
More information about the krbdev