Jonathan Steffan wrote:
I've been told the MIT system is unmaintained and broken.
Please start using subkeys.pgp.net
Indeed. GnuPG now uses subkeys.pgp.net
as it's default and GnuPG
developer David Shaw has recommended using a keyserver other than
numerous times on the gnupg-users list. The software used
is the PKS key server. It has the problems that
If the keyserver itself has become unreliable as well, that's another
strike against it. subkeys.pgp.net
is actually a DNS round robbin
record for 6 servers, so it should be a bit more reliable than a
As far as running a keyserver, that is a possibility, but doesn't seem
like anything that would be really necessary.
FWIW, the latest PKS code that I know of is at http://pks.sf.net/
The last time I built and packaged that was probably around the time
of their last release (in 2003). And it was a bit of a pain IIRC, due
to deps on an older Berkeley DB version.
There are a few different implementations for keyservers in use now.
I believe there are more keyservers using SKS than PKS these days.
SKS is written in Ocaml (and is also not just a simple configure,
make, make install piece of code): http://www.nongnu.org/sks/
The FAS just needs to be able to access the key someone has signed the
CLA with, right? Perhaps instead of requiring any particular
keyserver at all, the sign up could just let the user paste their key?
Then, with a little bit of pygpgme (or whatever glue you like), add
that key to an FAS keyring and verify the CLA signature. I could be
missing something obvious about why the process requires using a
keyserver, but it seems to me like that requirement could be removed
without much trouble.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
If electricity comes from electrons, does morality come from morons?