pgp.mit.edu

Ricky Zhou ricky at fedoraproject.org
Mon Feb 25 18:20:04 UTC 2008


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20080225/7322b496/attachment.sig>


More information about the Fedora-infrastructure-list mailing list