Question about fingerprints and keys uploaded to keyservers
dshaw at jabberwocky.com
Sat Feb 21 17:24:41 CET 2004
On Sat, Feb 21, 2004 at 05:08:32PM -0500, gabriel rosenkoetter wrote:
> On Sat, Feb 21, 2004 at 02:52:01PM -0500, David Shaw wrote:
> > We did. keyserver.net is, in fact, horribly broken in many ways (this
> > particular problem is just the tip of the iceberg). It's never worked
> > properly. I mailed them about fixing it a few years ago, but all the
> > mail disappeared into a black hole, so I gave up.
> That's wonderful, but Newton explicitly stated his key fingerprint
> 785F DFF3 7029 3FBD 45CE 747C 93CA E808 136F C036
> and that he'd sent the key to subkeys.pgp.net (by implication, in
> referencing that he'd sent it to the keyservers "in his signature")...
> which has never heard of keyid 136FC036 (as in, the last 64 bits
> of the fingerprint).
> So, unless you're suggesting that something about subkeys.pgp.net is
> also broken, there is something odd going on. Is synchronization
> between the various subkeys DNS RR servers flaky right now?
Might be. It happens every now and then that one server doesn't sync
for a bit.
> > As always, the answer is subkeys.pgp.net. It Just Works(tm).
> In this case, it would appear to have Just Not Worked, at least for
> a little while. :^>
Close enough. I'd change the slogan to "It Just Works More Often Than
The Other Solutions", but it doesn't read quite as well. ;)
Maybe the synchronization was slow for a bit. The SKS servers have
their own sync algorithm, and the PKS servers use email to sync. (SKS
uses email to sync with PKS). Either way, network connectivity is
needed (though the server must have had some connectivity to be able
to accept the key submission in the first place).
subkeys.pgp.net is made up of three machines in round robin rotation
(Jason's fixed PKS, and two SKS, if I recall). Who knows which one
the original key submissionw as sent to and which one you hit when you
tried. I keep meaning to show the IP address (under some high
verbosity level) that is used when making keyserver calls.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 330 bytes
Desc: not available
Url : /pipermail/attachments/20040221/7aa0b228/attachment-0001.bin
More information about the Gnupg-users