Package: profanity Version: 0.13.1-1~bpo11+1 Severity: normal X-Debbugs-Cc: debbug.profan...@sideload.33mail.com
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. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'testing'), (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages profanity depends on: ii libc6 2.31-13+deb11u5 ii libcurl3-gnutls 7.74.0-1.3+deb11u3 ii libgcrypt20 1.8.7-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1 ii libglib2.0-0 2.66.8-1 ii libgpgme11 1.14.0-1+b2 ii libgtk-3-0 3.24.24-4+deb11u2 ii libncursesw6 6.2+20201114-2 ii libnotify4 0.7.9-3 ii libotr5 4.1.1-4 ii libpython3.9 3.9.2-1 ii libreadline8 8.1-1 ii libsignal-protocol-c2.3.2 2.3.3-1 ii libsqlite3-0 3.34.1-3 ii libstrophe0 0.12.2-1~bpo11+1 ii libtinfo6 6.2+20201114-2 profanity recommends no packages. profanity suggests no packages. -- no debconf information
