gpg 2.0.11 reports invalid packets on keys from gpg 1.4.9 and keyservers

John Marshall john.marshall at
Sat May 23 07:47:09 CEST 2009

I was originally looking at this as a keyserver problem but it has been
pointed out to me that this problem cannot be reproduced with GnuPG

 - Using GnuPG 1.4.9, I can download key 0xFC05DA69 from any keyserver
   I've tried with no problem at all.
 - Using GnuPG 2.0.11, the only keyservers from which I have been able
   to download the key are SKS 1.0.10 keyservers.
 - If I download the key using GnuPG 1.4.9 and then use GnuPG 1.4.9 to
   export the key to a file, I can import that key with GnuPG 1.4.9 but
   not with GnuPG 2.0.11.  Also GnuPG 2.0.11 cannot read the key from
   the keyring to which GnuPG 1.4.9 imported it.

I have concluded that GnuPG 2.0.11 does not like the way that this key
is stored or exported by:
 - PKS 0.6.9
 - SKS 1.1.0
 - GnuPG 1.4.9

but GnuPG 1.4.9 works happily with all of these.  I think this probably
means that those three implementations are all broken, or that GnuPG
2.0.11 is not handling some corner case properly.

If I add --debug-all to the gpg imports, this is what I see:

Using GnuPG 2.0.11 (breaks):
  347 gpg: DBG: parse_packet(iob=1): type=2 length=540 (parse.import.c.376)
  348 gpg: DBG: parse_packet(iob=1): type=2 length=540 (parse.import.c.376)
  349 gpg: DBG: parse_packet(iob=1): type=13 length=42 (parse.import.c.376)
  350 gpg: DBG: parse_packet(iob=1): type=2 length=30 (parse.import.c.376)
  351 gpg: read_block: read error: Invalid packet

Using GnuPG 1.4.9 (works):
 1542 gpg: DBG: parse_packet(iob=2): type=2 length=540 (parse.import.c.372)
 1543 gpg: DBG: mpi_alloc(4096)
 1544 gpg: DBG: mpi_alloc_limb_space(4096)
 1545 gpg: DBG: parse_packet(iob=2): type=2 length=540 (parse.import.c.372)
 1546 gpg: DBG: mpi_alloc(4096)
 1547 gpg: DBG: mpi_alloc_limb_space(4096)
 1548 gpg: DBG: parse_packet(iob=2): type=13 length=42 (parse.import.c.372)
 1549 gpg: DBG: parse_packet(iob=2): type=2 length=30 (parse.import.c.372)
 1550 gpg: DBG: mpi_alloc(0)
 1551 gpg: DBG: mpi_alloc(0)

Data Point: Depending on the source, Key 0xFC05DA69 had more or less
 - 547 signatures (from SKS 1.0.10)
 - 548 signatures (from PKS 0.6.9)
 - 549 signatures (from SKS 1.1.0)

Perhaps SKS 1.0.10 silently ignores "problem" bits of the key?  GnuPG
2.0.11 was perfectly happy with the 547-signature edition of the key.

Please note that in an endeavour to eliminate discussion about
keyservers and armor, I believe I have reduced this to a pure GnuPG
native export/import issue across versions.

John Marshall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: </pipermail/attachments/20090523/42d5dac0/attachment-0001.pgp>

More information about the Gnupg-devel mailing list