OMEMO questions

Added lurch to a bunch of clients. Those that are on various versions of Windows do not work. At least one of them works with another one that is on Linux. I can’t find any obvious reasons for that.
When I ask users who are under Windows to enter /lurch status they get

Your contact does not support OMEMO

When I do so from Linux in a chat with either of them I get

OMEMO is enabled for this conversation

Linux client is 2.13.0. This is not changing.
Windows clients are 2.13.0 and 2.14.8.
All of them use the same set of libs: lurch 0.7.0, crypt 2.0.
How should I troubleshoot this?

I would expect that to work and I’m not seeing anything in the official issue tracker for lurch. That said is there anything in the debug window (help → debug window) when you type /lurch. Be sure to open the debug window first as it only shows new messages.

Your expectation is correct.
I don’t know how or why, but I logged in remotely and kept trying and it just began to work at some point. First, the title changed to (OMEMO available) and later to (OMEMO) and works since.

I’ll chalk it off as the power of your magic.

Now, there is another strange issue. I administer this whole infrastructure from my Linux box, and the rest are Windows boxes, but I have one other Linux user who also wants OMEMO.
I repeated the same steps of installing Lurch: copy to under ~/.purple and check off the plugin on the list.
But on their machine there is no lurch item in the plugin list. Why could it be missing when the .so is in place?
I did restart their Pidgin and check that libgcrypt and libgpg-error are installed.

I’ll chalk it off as the power of your magic.


But on their machine there is no lurch item in the plugin list. Why could it be missing when the .so is in place?

Open the debug window and then open the plugins window. That’ll causes pidgin to look at the plugins again and then it’ll spit out the error message. I’m guessing the compiled .so file doesn’t have the same libraries on the other machine. You’ll probably see something about a missing symbol or whatever.

Actually now that I think of it, make sure that libomemo is installed on the other machine, but the debug window will confirm that.

That said, purple-omemo is packaged for a few distros so that might be an option too.

Oh, this is strange! On my machine:

$ dnf provides libomemo
Last metadata expiration check: 0:00:17 ago on Mon 15 Apr 2024
Error: No Matches found
$ sudo find / -mount -name ‘libomemo*’

On the machine where it is not working I see in the debug window:

/home/user001/.purple/plugins/ is not loadable: cannot open shared object file: No such file or directory


$ ls -l /home/user001/.purple/plugins/
-rwxrw-r-- 1 user001 user001 1124696 Apr 14 18:06 /home/user001/.purple/plugins/

The same file works on my machine:

$ ls -l /home/whoami/.purple/plugins/
-rwxr-xr-x 1 user000 user000 1124696 Jun 29 2021 /home/user000/.purple/plugins/

Permissions on mine include others but should it matter?
I thought about selinux that could rear it ugly head and mess with the loading, but it is happily disabled.

Scratch that.
I pulled a full-blown development environment to the user’s machine and rebuilt the lib from source. Now it detects and runs.
The question remains, why. But it is probably to the lib’s dev, not to pidgin devs.

Yeah it’s most likely just a different version of the library or a flag or something in the build. This is one of the reasons why you can’t typically just share binaries on linux and other unix like operating systems, and why you need a “full” os install like in appimage, flatpak, and snaps.

That’s why I love static builds and wish everything that may be remotely portable (as in “moving from machine to machine”) was statically built. This is especially true for plugins like this one that do not have their own installer.
Having to build for every user’s on their machines is a bit of overkill requirement for things like userspace app plugins.

Well that’s were your distribution should be stepping in.

You do not say!

Still, something is finicky about OMEMO’s first sessions. It seems to go away after each party restarts their Pidgin or whatever they are using, but until then enabling Lurch does not help establish a session:

(12:26:11 PM) Your contact does not support OMEMO. No devicelist could be found.
(12:26:16 PM) Successfully enabled OMEMO.
(12:26:48 PM) user000: test
(12:26:51 PM) Even though an encrypted session exists, the recipient’s devicelist is empty.The user probably uninstalled OMEMO, so you can add this conversation to the blacklist.
(12:26:51 PM) test

Nope, they just installed it moments ago.

(12:26:49) Your contact supports OMEMO, but you have not established a session yet. Just start messaging!
(12:26:56) Successfully enabled OMEMO.
(12:27:01) Me: test
(12:27:04) Received omemo message that does not contain a key for this device

And it will go on like that until Pidgin is restarted. Since then everything is honkey dorey. Maybe it should be mandatory to restart it because users less technical than I am cannot easily figure it out on their own.