Would it make sense to change our docs to refer to subkeys.pgp.net instead of MIT?
John -------- Original Message -------- Subject: Re: GPG Keysigning at FUDCon Date: Thu, 3 Jan 2008 13:43:54 -0500 From: Todd Zullinger tmz@pobox.com Reply-To: Development discussions related to Fedora fedora-devel-list@redhat.com To: fedora-devel-list@redhat.com References: 20071212214010.GA20896@auslistsprd01.us.dell.com 477C3AA7.9010700@redhat.com 1199353983.13378.1.camel@rousalka.dyndns.org 477D1646.6080207@redhat.com
John Poelstra wrote:
I looked into it more and changed the expiration by:
- gpg --edit <key> and then option "expire"
- gpg --keyserver pgp.mit.edu --send-keys <key> to make change
public
FWIW, you may want to send that to subkeys.pgp.net, which is where Matt plans to pull the keys from for the key signing. This is the default keyserver in recent gnupg releases. I think that there is a sync between pgp.mit.edu and subkeys.pgp.net, but I'm not positive.
The gnupg default is subkeys.pgp.net because pgp.mit.edu runs ancient keyserver software that has many known problems (it ignores photo packets, can munge up multiple subkeys, and other annoyances).
On Thu, 2008-01-03 at 10:49 -0800, John Poelstra wrote:
Would it make sense to change our docs to refer to subkeys.pgp.net instead of MIT?
It would, if the recommended GUI tools defaulted to subkeys.pgp.net as well. Otherwise there's somewhat of a logical disconnect. I see that the current maintainer of Seahorse may be running up against -ENOTIME.
On Thu 03 Jan 2008, John Poelstra wrote:
Would it make sense to change our docs to refer to subkeys.pgp.net instead of MIT?
Personally, I followed the instructions in your wiki exactly, and they did not work.
I created a gpg key, and took the asci version to pgp.mit.edu, and it worked perfectly.
I tried accessing subkeys.pgp.net, and I got re-directed to http://lists.maluska.de/mailman/listinfo which firefox could not find.
Maybe I'm lucky, but as far as I am concerned MIT runs a service for registering pgp keys, which works perfectly well in a completely transparent way. You register your key, and then you check that it is registered.
I see absolutely no advantage is following an indirect route which achieves the same thing (if it works, which it doesn't for me) in a mysterious and roundabout way.
docs@lists.stg.fedoraproject.org
-
John Poelstra -
Paul W. Frields -
Timothy Murphy