pgp.mit.edu

[Todd Zullinger]

Ricky Zhou wrote:
>> 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. 

Ahh, I hadn't thought about the potential of a legal reason to use a
public keyserver.

Having a FAS keyring with all the contributors keys could be handy
too, for those of us that use gpg regularly.  Debian has a package of
their gpg keyring even: http://packages.debian.org/debian-keyring :)

But that's much outside of the CLA's need for gpg of course.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reason obeys itself; and ignorance does whatever is dictated to it.
    -- Thomas Paine

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20080225/fca44b84/attachment.sig>