[Pkg-xmpp-devel] Bug#1026430: profanity: If an OMEMO msg to 2+ recipients & 1 recipient’s pubkey is bad, the msg is sent anyway (a logistical mess)

[debbug.profanity at sideload.33mail.com]

Package: profanity
Version: 0.13.1-1~bpo11+1
Severity: normal
X-Debbugs-Cc: debbug.profanity at 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