Package: profanity Version: 0.13.1-2 Severity: normal Tags: upstream X-Debbugs-Cc: debbug.profan...@sideload.33mail.com
The Profanity user guide¹ states “Before you can start talking with a contact you need to authenticate him by trusting his fingerprint(s).” That seems to be true for some correspondents but not others. I have four people configured as follows: * Alice - trusted fingerprint * Bob - untrusted fingerprint (implicit distrust) * Freddie - untrusted fingerprint (implicit distrust) * Martin - untrusted fingerprint (implicit distrust) My trustmodel is “manual”. All those users are using Snikket on iOS and the server is also Snikket. OMEMO is always enabled for all those users. According to the documentation, only Alice should be able to receive messages from me in this situation. However, Alice, Freddie, and Martin all seem to receive messages from me. Bob is exceptionally plagued with a false error claiming lack of OMEMO support every time I send Bob a msg. Apart from the error message being false, msgs to Bob are rightfully dysfunctional (though I would prefer if he receives no msg at all - what’s the point of sending him a msg he cannot open?). Msgs to Alice are rightfully functional. But what about Freddie & Martin? They generally receive my msgs fine, yet I apparently did not trust their fingerprints. This suggests a noteworthy security vulnerability because an untrusted key should not be used with a trust model of /manual/. Alternative theory 1: I did not keep notes on whose fingerprints I trusted. I am surprised I did not trust Freddie’s key. So I wonder if Profanity might be lying about whether keys are trusted. After entering /msg Freddie to get a dedicated 1:1 window, I entered “/omemo fingerprint” and it showed a fingerprint. It does not say trusted or untrusted. But if I do the same for Alice, “(trusted)” is printed next to the fingerprint. So by the way, the absence of “(trusted)” is an incredibly cryptic way of telling users a key is untrusted. I struggled to trust the software. So I found this file: ~/.local/share/profanity/omemo/$my_acct/trust.txt And indeed the fingerprints for Bob, Freddie, and Martin were not there. So I think we can rule out the alternative narrative that Profanity is lying about which keys are trusted. Alternative theory 2: Perhaps the “OMEMO” tag in the window status bar is a lie, and Profanity is actually sending unencrypted payloads to Freddie & Martin. This also seems unlikely but I will ask them if Snikket shows a padlock or shield on messages they receive from me. If not, I’ll amend this ticket. Otherwise assume they are getting a padlock. ¹ https://profanity-im.github.io/guide/0131/omemo.html -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages profanity depends on: ii libc6 2.36-9+deb12u7 ii libcurl3-gnutls 7.88.1-10+deb12u5 ii libgcrypt20 1.10.1-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgpgme11 1.18.0-3+b1 ii libgtk-3-0 3.24.38-2~deb12u1 ii libncursesw6 6.4-4 ii libnotify4 0.8.1-1 ii libotr5 4.1.1-5 ii libpython3.11 3.11.2-6 ii libreadline8 8.2-1.3 ii libsignal-protocol-c2.3.2 2.3.3-3 ii libsqlite3-0 3.40.1-2 ii libstrophe0 0.12.2-1 ii libtinfo6 6.4-4 profanity recommends no packages. profanity suggests no packages. -- no debconf information
