gpg 2.0.11 reports invalid packets on keys from gpg 1.4.9 and keyservers
john.marshall at riverwillow.com.au
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the Gnupg-devel