keys that GnuPG doesn't like with --recv/--refresh

[Jason Harris]

On Wed, Aug 10, 2005 at 04:57:32PM +0200, Peter Palfrader wrote:

> key 0x39CC8CED3D79EDCA as found on keyserver.noreply.org (or any other
> server of the SKS network) makes GnuPG 1.4.2 fall over itself on --recv/--refresh:

Interestingly (albeit with the key fetched from keyserver.kjsl.com),
GPG only does this when importing an armored version of the key:

  %esha1sum lookup
  fb196917496fbb5d533cf5a6a402a887cdf6a680        11364   lookup

Importing a dearmored ("gpg --dearmor lookup") version of the key:

  %esha1sum lookup.gpg
  235c953f05bd2334c7c74cbb60c44233bc2c0824        8192    lookup.gpg

produces no errors.  Also, importing the key with others (in one armored
keyblock):

  %curl 'http://keyserver.kjsl.com:11371/pks/lookup?op=get&search=Marc%20SCHAEFER' | gpg --import

produces no errors.

GPG gets multiple armored keyblocks from gpgkeys_hkp during the --refresh
you mentioned, Peter, and is choking on the end of the second keyblock,
apparently, so the third keyblock doesn't get processed.  During a "--recv
0x3D79EDCA," it only gets one keyblock, which doesn't cause an error
until _after_ 0x3D79EDCA is already imported.

NB:  Fetching the key from pgp.mit.edu doesn't cause this error.
The kjsl and MIT query outputs (respectively) end with:

  %tail -5 lookup lookup.1
  ==> lookup <==
  7I6jM8w/O6mIRgQYEQIABgUCPQIoMAAKCRA5zIztPXntynFGAJ9sPZd9EGprjp1z
  2J4/+PMVXnntuACfR8ZsukCCfDUeU7Qgfz+X5BMoM94=
  =yz3b
  -----END PGP PUBLIC KEY BLOCK-----
  </pre>

  ==> lookup.1 <==
  8ZoZnplT7I6jM8w/O6mIRgQYEQIABgUCPQIoMAAKCRA5zIztPXntynFGAJ9sPZd9
  EGprjp1z2J4/+PMVXnntuACfR8ZsukCCfDUeU7Qgfz+X5BMoM94=
  =Bva6
  -----END PGP PUBLIC KEY BLOCK-----
  </pre>

and end with the same subkey sig. packet (when dearmored and gpgsplit):

  2406ea5bb3544178efabfe4ec85b33c6f7361d90        72      000040-002.sig
  2406ea5bb3544178efabfe4ec85b33c6f7361d90        72      000041-002.sig

So, there seems to be some difference between "gpg --dearmor" and
"gpgkeys_hkp | gpg ..." when interpreting armored data.

-- 
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris at widomaker.com _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 313 bytes
Desc: not available
Url : /pipermail/attachments/20050810/2d2bf919/attachment.pgp