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.

dkg created this task.Jun 14 2018, 6:28 AM
werner triaged this task as High priority.Jun 14 2018, 8:07 AM
werner removed a project: dirmngr.
stm added a subscriber: stm.Jun 14 2018, 4:29 PM
ilf added a subscriber: ilf.Jun 16 2018, 7:56 PM
georg added a subscriber: georg.Jun 17 2018, 1:14 PM
werner claimed this task.Jul 4 2018, 9:20 AM
werner closed this task as Resolved.Jul 4 2018, 10:19 AM

Fixed for master and 2.2.9.

stm added a comment.Jul 4 2018, 9:56 PM

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;
werner added a comment.Jul 5 2018, 9:04 AM

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.