That was one of the problems IIRC. Instead of inheriting the global setting choice of Tor as proxy, the new accounts are oblivious to this and use the Transport by default. There is no way to configure all new accounts to be Tor aware.
has anyone managed to have gajim work with omemo encrypted group chat? so far, i have been unable to accomplish this. tested it on conference.jabber.ccc.de. but, the omemo button never becomes active.
[edit: i got it working. a few of the room settings need to be tweaked. members only. broadcast of full jabber id. persistence.]
on another note, i also cannot get otr working with it right now. it simply won’t see the plugin.
coyim has been the absolute easiest that i have tested so far. gajim has presented a number of issues that are certainly not new user friendly. however, coyim currently has not mechanism to block people that are not on your contact list from messaging you, which is a deal breaker for me at the moment. it opens up new users to a number of potential attack vectors.
the more i mess with gajim, the less confident i’m becoming in it. for unknown reasons, sometimes the omemo button doesn’t appear for various accounts. but, it will be there on another startup. as far as multi-user chat with xmpp and omemo is concerned, one of the accounts i created to test it failed open. for whatever reason, omemo was not enabled for the one account in the multi-user chat, despite having been enabled in all the one-on-one windows. thus, with omemo disabled, it sent an unecnrypted message to the channel. the xmpp specs for multi-user chat involves the server logging messages. so, this could be a particularly bad accident for someone to have.
Yes, this is a missing feature:
i don’t think this is a missing feature, @patrick. it feels like a bug. all of this occurred after i manually installed the omemo plugin and enabled it. i’ve had inconsistent results with the functionality of the plugin. so far, it has ranged from the following:
in chat window, omemo “fish” icon button does not appear. it simply is not accessible. yet, it’s accessible in others with no rhyme or reason.
fingerprints are not exchanged. while account a can receive fingerprint from account b, account b does not receive fingerprint from account a. thus, communication is blocked.
in multi-user chat, omemo is enabed by default with some accounts, and not with others. i have yet to figure out what caused this, if anything. but, as noted above, this could be a serious liability.
unfortunately, it is not apparent that having omemo installed out of the box would address the above problems. i’m going to play around with it some more. if i have receive the same results on different machine configurations, i may file some bug reports with the developers.
OMEMO in comparison with OTRv4 , OTRv4 way better which Gajim itself doesnt use it. i prefer CoyIM but still in testing phase.
coyim is an open door for receiving messages at the moment. there is no built in feature to prevent who can send messages to a user, which is a great open attack vector. the next version of coyim plans to address this based on what i saw on their project page. i’m hesitant to recommend coyim at the moment for anything other than one off conversations on disposable accounts, especially to newer users.
Thanks for testing it. Can you please report this bug upstream and link to it here?
let me play with it some more. i want to make sure i can replicate this elsewhere so it isn’t blown off as a whonix or virtualbox issue. anyone else dealt with similar in their configs?
3 posts were split to a new topic: coyIM using OTRv4? Nope
i’ve still encountered the random error where, for whatever reason, the omemo encryption button for the conversation is not appearing in a chat.
as a side concern, since omemo does allow for group chats, i’ve found ways to continue to fail to encrypt messages with ease.
i’m still playing with it to see if i can isolate a cause. however, for the time being, this is why i went with coyim in the latest version of the guide i’m working on. while coyim is very basic and is missing some important features, i’ve yet to encounter a scenario where the encryption options utterly fail.
That’s a serious problem can you please report it to them?
let me run through the tests again. it’s not a bug in the group chats iirc. it’s a design problem i believe.
I want to ask for advice on GPG chats in Gajim on Whonix.
Gajim uses GPG keys. Passwords of these keys can be stored in Gnome-Keyring or GPG-agent. Whonix does not caches passwords. And GPG passwords must be entered many times in Gajim:
- at every disconnection or status change
- each log in into account
- about once in half an hour.
This leads to problems with message delivery and makes GPG chatting difficult or impossible.
I see different solutions:
- Settings of GPG agent:
- add this new line to sudo nano /usr/lib/python3/dist-packages/gajim/application.py Gajim developers do not want or cannot add it in Debian repo.
- Gajim / Preferences / Use PGP Agent
- Gajim / Preferences / Advanced / Advanced configuration editor / use_gpg_agent / Activated
- Enable password caching:
GPA / Edit / Backend preferences / Level: Expert.
GPA / Edit / Backend preferences / Private Keys / default-cache-ttl / set 86400 / Apply / Ok.
GPA / Edit / Backend preferences / Private Keys / max-cache-ttl / set 86400 / Apply / Ok.
This solution increases the time between entering passwords. But the messages may not reach the recipient if you send it during the period when the recipient saw a opened window for entering the GPG-password. No messages and no notification.
- Store passwords in Gnome Keyring instead of GPG agent (without save in password manager):
sudo apt-get update
sudo apt-get install gnome-keyring
- Run Gajim and set up GPG
- create the main password for Gnome Keyring. This password must be entered each time when Gajim starts.
- put down the keys in Gnome keyring and do not save GPG-passwords of in password manager. GPG-password must be entered each time when Gajim starts and approximately once a day.
But there is missing message again. The messages may not reach the recipient if you send it during the period when the recipient saw a opened window for entering the GPG-password. No messages and no notification.
3) Store passwords in Gnome Keyring instead of GPG agent and save password in password manager
The same manual as in solution 2 but you save password of GPG keys in password manager. You should enter the main password of Gnome Keyring once after the start og Gajim. But GPG-keys passwords are already saved, you do not need to enter time after time.
I will check further. But I don’t see the issue with missing messages in solution 3. It’s good.
The easiest and most convenient solution is 3. Does it safe? Can other apps get saved GPG-passwords?
I use a separate Whonix Workstation for Gajim only. No surfing or any other activity.
Have gajim’s omemo issues been fixed? A small implementation bug caused different omemo clients to be incompatible with one another.
I wouldn’t use GPG because if it is every compromised, all previous conversations can be decrypted while OMEMO protects against it.
I used Gajim on Whonix with Conversation on Android. Everything was well.
Gajim does not download or decrypt any history from server if you disable it (at the Gajim settings). An attacker can do this if he received:
- password of JID
- private GPG key
- password of GPG key
This is result of physically accessing to powered-on computer or hacking the system.
And such attacker can also download the entire OMEMO-history. Messages, time, senders, recepients are visible in OMEMO logs. OMEMO texts cannot be read.
OMEMO does not allow Workstation booting from the clean snapshot. It’s great issue. You are obliged to save all changes which were made while using the chat. For example, you received a dangerous file or you opened a dangerous link. Can you restore the last clean snapshot? Yes but you will stop receiving OMEMO messages from the contacts.
GPG allows booting from clean snapshots. This is a very good.
Reported to Debian:
Reason for removal of gajim in Whonix 16 (Debian buster based) if not fixed in time?
Tracking for #milestone_whonix_16.