On 2008-02-25 12:53:22 PM, Todd Zullinger wrote:
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.
+1 for using
subkeys.pgp.net. That's what FAS2 will probably
end up
using, and I've been wanting to ask about moving FAS1 over and updating
our docs on generating/uploading keys to work for both FAS1/2.
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.
For what it's worth, this would make it way easier to
implement from the
pygpgme side. Right now, I don't see any nice mechanism for downloading
keys from the keyserver (although I might just be missing it), and the
current CLA code uses kind of a hack with keyserver-options auto-key-retrieve,
which only works when we're verifying a signature.
I'm not sure if there's some legal purpose to requiring the key to be on
a public keyserver, though (and I think it ends up being more
convenient/useful if we end up pulling from an online keyserver.
Thanks,
Ricky