Strange Key ID problem. : subkey id is reported where primary key id should be reported as missing?
JPClizbe at tx.rr.com
Mon Jun 29 09:59:30 CEST 2009
Werner Koch wrote:
> On Mon, 29 Jun 2009 07:56, chiaki.ishikawa at ubin.jp said:
>> (After writing this summary, I now think it is a bug, but am not sure
> Yes it is a bug. But not in GnupG but in the keyserver software.
>> So I tried to obtain the key using gpg with arguments such as
>> --keyserver pgp.mit.edu -recv-keys 17785FE8
>> --keyserver pgp.nic.ad.jp -recv-keys 17785FE8
>> to no avail.
> Both keyservers run old and non-OpenPGP compatible software - Do not use
> I tried this too (using gpg2 but that doesn't matter)
> So everything is fine. The key was taken from one of the SKS keyservers
> to which keys.gnupg.net resolve. If you now look at the key:
The key shows correctly on the SKS servers:
> We do have this problem for years now and at least the admins of
> pgp.mit.edu don't care about it and keep on running this broken
And we keep on giving the same advice over and over not to use this and
other broken PKS servers.
> I am now considering whether we should detect
> Server: pks_www/0.9.6
> and reject this one as entirely broken. Maybe just a warning if
> --expert is used.
No complaints here. Maybe it would push the PKS admins to upgrade.
I doubt anyone is interested in making the PKS code RFC compliant.
John P. Clizbe Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or
mailto:pgp-public-keys at gingerbear.net?subject=HELP
Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 679 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-devel