We've noticed the following problem with Debian Jessie (2.0.26-6) and I've also
checked that this happens with 2.0.28:

• User has a mail signed by a PGP-2 key. (e.g. 0xBF85AB31)

• Verifiying this with gpgparsemail gives you:

gpg: Signature made Mon 27 May 2013 01:04:45 PM CEST using RSA key ID BF85AB31
gpg: Note: signatures using the MD5 algorithm are rejected
c [GNUPG:] SIG_ID i99YU0xsFZXBhWvkV4R/fNpcgUs 2013-05-27 1369652685
c [GNUPG:] GOODSIG 9BA06915BF85AB31 [uncertain] Matthias Kalle Dalheimer
(Company address) <kalle@kdab.net>
gpg: Good signature from "Matthias Kalle Dalheimer (Company address)
<kalle@kdab.net>" [uncertain]
c [GNUPG:] VALIDSIG 00000000000000000000000000000000 2013-05-27 1369652685 0 3 0
1 2 00 00000000000000000000000000000000
c [GNUPG:] TRUST_FULLY

• Kleopatra takes that fingerprint (00000000000000000000000000000000) and uses

it to look up more information about that key.

• If you have another PGP-2 key (e.g. 0x23F5ADDB) in your pubring this can

return the wrong key.

If you do:
gpg --list-key 00000000000000000000000000000000

It shows you all the PGP-2 keys in your keyring.

• Kleo (or gpgme, have to check) just takes the first key where the fingerprint

matches and shows the validity information based on this key.

• The validity of the signature is checked against key 1 and the validity of the

key is checked against key 2.

This leads to the scenario where I can spoof KMail into showing valid signatures
coming from the last PGP-2 key in your public keyring by using another PGP-2 key
even if you never trusted that other key.

I'll fix in kleopatra that zero fingerprints are rejected.

But GnuPG should either reject working with such keys (like gpg 2.1 does) or
properly handle them.

If needed I can send you the test data privately. I don't have a PGP-2 testkey
at hand to generate an anonymized test case.