Bug#1017049: profanity: No acknowledgement when running “/omemo start” in a chat room; also no docs on this
On Fr, 12.08.2022 12:58:51, debbug.profan...@sideload.33mail.com wrote: > Package: profanity > Version: 0.10.0-1 > Severity: normal > Tags: upstream > > To send encrypted messages to a chat room, the following steps are > necessary: > > 1) OMEMO must be switched on for that room (enter “/omemo start” within > that room) > 2) the fingerprint of every person in that room must be trusted > «OR» > 2) enable blind trust (“/help omemo trustmode” in some versions) > > When step 1 is performed, there is no response from the app in that > window. There is also no response in window 1. No error message > either. So it appears to the user that their command was ignored. When OMEMO has been enabled, there should be "[OMEMO]" in the titlebar. Just beside of the room title. It also should disappear with /omemo end. In case of error, you will see some error message like: ! You have not generated or loaded a cryptographic materials, use '/omemo gen' > In my case, the command had proper effect (so egress messages > thereafter were encrypted). But the user should be told > something like: > > “OMEMO enabled for outbound messages to this channel. >To reverse this action, run `\omemo end`” > > It would perhaps also be useful when entering a chat room that has > OMEMO disabled to automatically print a banner saying: > > “Warning: messages sent to this room will be unencrypted. >To enable e2ee run `\omemo start` in this window.” Some people prefer E2EE, some not. If profanity will print this warning all the time, it will be a little bit annoying. One example is public non-anonymous group chats. There are also clients which doesn't used OMEMO at all. > Also, “/help omemo” does not cover this use case. The page gives the > proper BNF syntax (“/omemo start []”), but it fails to > mention that “” cannot be a /room/, and that the only way to > start a session for a room is to do “/omemo start” in that room. Maybe this is an issue. Thanks for the report. > So there are three bugs here: > 1) lack of command acknowledgement > 2) lack of warning banner in unencrypted rooms > 3) lack of help docs Keep in mind there where some issues with OMEMO in 0.10.0. Some issues has been fixed in 0.11.0 / 0.12.0. -- Stefan Diese E-Mail wurde von einem Debian GNU/Linux System gesendet
Bug#1017049: [Pkg-xmpp-devel] Bug#1017049: profanity: No acknowledgement when running “/omemo start” in a chat room; also no docs on this
On 2022-08-12 12:58, debbug.profan...@sideload.33mail.com wrote: > Package: profanity > Version: 0.10.0-1 Could you please check, if version 0.12.1-1~bpo11+1 solves the issue? To install it on Debian 11, perform the following steps: $ echo "deb https://deb.debian.org/debian bullseye-backports main" \ | sudo tee /etc/apt/sources.list.d/backports.list $ sudo apt update $ sudo apt install -t bullseye-backports profanity Thank you!
Bug#1017049: profanity: No acknowledgement when running “/omemo start” in a chat room; also no docs on this
Package: profanity Version: 0.10.0-1 Severity: normal Tags: upstream X-Debbugs-Cc: debbug.profan...@sideload.33mail.com To send encrypted messages to a chat room, the following steps are necessary: 1) OMEMO must be switched on for that room (enter “/omemo start” within that room) 2) the fingerprint of every person in that room must be trusted «OR» 2) enable blind trust (“/help omemo trustmode” in some versions) When step 1 is performed, there is no response from the app in that window. There is also no response in window 1. No error message either. So it appears to the user that their command was ignored. In my case, the command had proper effect (so egress messages thereafter were encrypted). But the user should be told something like: “OMEMO enabled for outbound messages to this channel. To reverse this action, run `\omemo end`” It would perhaps also be useful when entering a chat room that has OMEMO disabled to automatically print a banner saying: “Warning: messages sent to this room will be unencrypted. To enable e2ee run `\omemo start` in this window.” Also, “/help omemo” does not cover this use case. The page gives the proper BNF syntax (“/omemo start []”), but it fails to mention that “” cannot be a /room/, and that the only way to start a session for a room is to do “/omemo start” in that room. So there are three bugs here: 1) lack of command acknowledgement 2) lack of warning banner in unencrypted rooms 3) lack of help docs -- System Information: Debian Release: 11.4 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-16-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+deb11u3 ii libcurl3-gnutls7.74.0-1.3+deb11u1 ii libgcrypt201.8.7-6 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 libotr54.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 libstrophe00.10.1-1 ii libtinfo6 6.2+20201114-2 ii libx11-6 2:1.7.2-1 ii libxss11:1.2.3-1 profanity recommends no packages. profanity suggests no packages. -- no debconf information
