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
Attachment:
pgpd79B8HqvJg.pgp
Description: PGP signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
