Odd behaviour of option --list-packets
Open, LowPublic

Description

I have recognized a strange behaviour of GnuPG while parsing public keys with option --list-packets. With low verbosity level (zero or one "-v" options) it runs without complaints. However, with "-v -v" I've got the following error:

$ cat 9C0346E338FC9E03.asc |gpg --list-packets -v -v
[...]

off=154384 ctb=89 tag=2 hlen=3 plen=622

:signature packet: algo 17, keyid 9C0346E338FC9E03
version 4, created 1372273960, md5len 0, sigclass 0x18
digest algo 2, begin of digest 52 6d
hashed subpkt 2 len 4 (sig created 2013-06-26)
hashed subpkt 27 len 1 (key flags: 02)
hashed subpkt 9 len 4 (key expires after 5y0d0h0m)
subpkt 16 len 8 (issuer key ID 9C0346E338FC9E03)
subpkt 32 len 540 (signature: v4, class 0x19, algo 1, digest algo 2)
data: [160 bits]
data: [158 bits]

off=155009 ctb=88 tag=2 hlen=2 plen=48

gpg: buffer shorter than subpacket
gpg: signature packet without timestamp
gpg: buffer shorter than subpacket
gpg: signature packet without keyid
gpg: buffer shorter than subpacket
:signature packet: algo 1, keyid 0000000000000000
version 4, created 0, md5len 0, sigclass 0x12
digest algo 2, begin of digest ff 7b
hashed subpkt 18 len 4 (?)
gpg: buffer shorter than subpacket
data: [158 bits]

I can provide the buggy public key, if requested. The length of the unhashed subpacket section in this signature packet seems to be wrong and differs from length given in the subpacket itself.

Details

Version
gpg (GnuPG) 2.2.1
stm created this task.Nov 24 2017, 6:36 PM
stm triaged this task as Low priority.Nov 25 2017, 6:21 PM
stm added a comment.Nov 25 2017, 6:23 PM

After having a look at the code base I guess this behaviour is intentional.