Jonathan Steffan wrote: > I've been told the MIT system is unmaintained and broken[1]. > > 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 pgp.mit.edu numerous times on the gnupg-users list. The software used by pgp.mit.edu is the PKS key server. It has the problems that Jonathan quoted. 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 single server. 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?
Attachment:
pgpoh4joBVFVg.pgp
Description: PGP signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
