pgplegacy plugin (XEP-0027) introduces keyid assignments from untrusted source

Problem description

Presence stanza handler receives presence status from server and verifies if it is signed by ANY key known to keyring. If it's true and presence sender contact has no key already assigned, handler will update key ID associated with sender. Therefore once you have established PGP communication with some person (their client learned your key), you may use XMPP server to spoof keys for attacked person's contacts and perform MITM. Still, there are pretty narrow case when it works (for fresh installs for example), but in fact any trust to key-account bindings imposed by server breaks E2EE.

Ways of mitigation

Root of problem is an XEP-0027 proposal. Apart from poor definition why peers have to perform stanza signing and how to handle verification failures, it suggests questionable practices to sideload keys once encrypted presence stanza received:

All keys are exchanged using OpenPGP key servers, and usually are retrieved when a signed stanza is received (key retrieval does not happen in-band).

It's not even clear how to find key using only JID and authenticate it. Even if keys are located, such approach centralizes key trust in group of servers which replicate keys among themselves while PGP is aimed for decentralized trust in the first place. So far manual control of assigned PGP keys to contacts appears to be the only viable option.

The only useful thing we can do with signed presence status text is to verify it's content and mark or discard it if it's signature is invalid (can't be verified or doesn't match assigned key fingerprint). I don't know gajim modules API features, but first thing which comes to my mind is to add prefix "[BAD SIGNATURE] " to status text if it fails to verify.