If a message is sent in a chat room with multiple recipients, and
Profanity fails to get a handle on the public key for one of the
recipients, Profanity simply neglects to use the key it needs and
sends the msg anyway to all recipients. So the recipient whose pubkey
was neglected receives a non-decryptable message which then manifests
into a bogus error falsely telling the recipient that their XMPP
client does not support OMEMO (which apparently is the text portion of
the message).
Scenario:
Suppose Rob & Rennae are recipients of Sam’s msg, and Rennae’s
pubkey was lost. Rob receives the msg okay but he does not likely
know that the msg failed for Rennae. Sam expected both recipients to
receive the same msg at roughly the same time. So Sam is forced to
scramble to solve the pubkey problem and quickly send a copy to
Rennae. But Sam does not want Rob to recieve duplicate copy of the
same message, so Sam must resend the msg just to Rennae. Sam also
must tell Rennae that he botched the transmission, and also tell
Rennae that Rob already received the same message. Rennae must trust
that Sam did not alter the message. This nightmare of a bug causes
embarrassment for Sam and demoralizes Rob & Rennae as far as XMPP
goes.
There are actually 4 bugs here:
1. (already reported) Profanity failed to find the public key for
recipient even though Profanity recently just used the pubkey
successfully. This bug has already been reported separately (bug
1024899)
2. All or nothing policy needed-- when a msg is known to fail for a
group, Profanity should not send the msg to anyone. Profanity did not
even warn the sender of the problem; it just took the liberty of
encrypting the msg to X recipients and transmitting it to Y
recipients, where X > Y. Only after the transmission does Profanity
inform the sender of the problem. This creates a logistical mess for
the sender. In the scenario given, Profanity should either refuse the
send the message entirely, or it should give Sam an informed choice to
send the message anyway knowing that delivery will be botched and
problematic.
3. When a msg is expected to fail for one recipient among many,
Profanity should not send it to recipients where it is known to
fail. Notwithstanding bug 2 above, even if a sender opts to send a
message anyway, there is still no reason to transmit the msg to the
recipient who Profanity knows cannot decrypt it.
4. The error msg seen by the recipient is (apparently) the text
portion of the encrypted payload, which generically tells the
recipient that their client does not support OMEMO. The receiving
client simply presents that text to the user of that client. This
message is bogus. Just because Profanity cannot find the pubkey does
not mean the receiving client does not support OMEMO. The text msg
should not take liberties of making speculative or unlikely claims
about what the issue is. Profanity also should not assume when
phrasing the text that the bug or deficiency is necessarily on the
recipient’s side.