Page MenuHome GnuPG

too-large User ID packets result in dropping an entire certificate
Closed, ResolvedPublic


take this example:

0 dkg@alice:/tmp/cdtemp.Yn2eYN$ gpg --recv 0x16E0CF8D6B0B9508
gpg: packet(13) too large
gpg: read_block: read error: Invalid packet
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
2 dkg@alice:/tmp/cdtemp.Yn2eYN$ gpg --list-keys
0 dkg@alice:/tmp/cdtemp.Yn2eYN$

and yet, the certificate 0x16E0CF8D6B0B9508 on the public keyservers does have good key material in it (despite some of its packets being spoofed/bogus/nonsense)

This was reported as part of an issue with sks, but i think the most important short-term part of the fix should be GnuPG client side -- it should simply drop packets that it refuses to process, without dropping the entire certificate.



Event Timeline

werner triaged this task as High priority.Jun 14 2018, 8:07 AM
werner removed a project: dirmngr.

Fixed for master and 2.2.9.

What happens, if other bad packets beside PKT_USER_ID, PKT_ATTRIBUTE, PKT_OLD_COMMENT, and PKT_COMMENT are found?

      log_error("read_block: read error: %s\n", gpg_strerror (rc) );
      goto ready;

It won't import that keyblock. We can fixup some trivial cases but there will always be ways to create a garbled keyblock and that is nothing we can fix. Better restore the keyblock from a backup or write a dedicated tool fsck-like tool.