OMEMO for XMPP on FreeBSD

sidetone

sidetone

While XMPP clients work consistently well, OMEMO seems to not always work how it has worked before according to memory or to notes. While communication to the server is encrypted, communication needs OMEMO to be secure through the server as well, so only endpoints can view the data.

In the past, dependencies mostly related to cryptography had to be updated, to get OMEMO in working status again.


OMEMO versions
The newest implementation of OMEMO uses the namespace of "urn:xmpp: omemo:2" since XEP-0384 version 0.8.0 released in late 2021. OMEMO:1 which used "urn:xmpp: omemo:1" was intended as the future proof version. I'm uncertain if OMEMO:2 is compatible with OMEMO:1. OMEMO:0 is obsolete, which Siacs OMEMO previously replaced.

The most widespread implementation of OMEMO has been Siacs OMEMO stewarded by Conversations, which has used the namespace of "eu.siacs.conversations.axolotl". This was for XEP-0384 versions 0.2.0 until 0.3.0. This Siacs version of OMEMO is incompatible with other versions of OMEMO. As of January 2021, Conversations has been using Siacs OMEMO. Since then, uncertain which version of OMEMO Conversations currently uses. https://wiki.xmpp.org/web/Tech_pages/OMEMO

Histories of namespaces used by OMEMO (and subsequently its versions) are included in https://xmpp.org/extensions/xep-0384.html. Also to note, while OMEMO (XEP-0384) is an experimental standard, its implementations for certain sets of messengers are standards as features.

OMEMO client/server status
https://compliance.conversations.im/ indicates if an XMPP server has compatibility with the OMEMO version that Conversations uses, and it also indicates compatibility of servers with other XMPP extensions (XEP's) which Conversations also uses.

https://omemo.top/ has the status on any implementation of OMEMO for XMPP clients. The site has been around for a few years, yet development of OMEMO on XMPP seems to have halted on some clients. The bounty website is down at the time of this writing. Some other links are outdated as well.

Mozilla has an XMPP feature for Thunderbird, but there's no OMEMO extension for it.


In the past, net-im/gajim, and net-im/dino have worked well with OMEMO on FreeBSD. Gajim version 1.8.1 uses Siacs OMEMO, while the current Gajim version available on FreeBSD is 1.3.3. OMEMO for XMPP on net-im/pidgin (through net-im/lurch) has worked recently with mixed results. Uncertain of the reasons that these haven't worked well recently, whether it has to do with different OMEMO versions being on each client, or my computer configuration.

There's net-im/coyim (in Golang) which uses OMEMO encryption (OTR) by default, and doesn't need it to be configured. On FreeBSD, at least, it requires use of Tor. While that's great for some people's purposes, that can be excessive for the average need.

Libervia and Moxxy, not available on FreeBSD, have been used with OMEMO:2. https://xmpp.org/2023/08/the-xmpp-newsletter-june-july-2023/ https://libervia.org/news. Twomemo is an OMEMO:2 backend for Python.


Leave updates or share your experience on what you use with XMPP OMEMO on FreeBSD, including for use between FreeBSD and mobile devices. Tell which client you use on FreeBSD for OMEMO on XMPP/Jabber, or what has worked for you.
 
It was brought to my attention that, for Gajim to be updated to 1.8.1, Python dependencies including for cryptography need to be fixed -> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271876

Back to types of OMEMO
The Prosody server uses Siacs OMEMO (https://modules.prosody.im/mod_omemo_all_access.). There's not much information on the net about EJabberd, as it may take looking at the code to figure out. It seems that EJabberd server uses Siacs OMEMO and it can possibly be configured to use other forms of OMEMO.

Console XMPP client Profanity uses Siacs OMEMO (0.3.0). It may need to be compiled with the OMEMO configuration option, and the fingerprint has to be enabled on the command line. https://profanity-im.github.io/xeps.html, https://profanity-im.github.io/guide/latest/omemo.html

There's not much information on clients which use OMEMO:1. Clients Moxxy and Libervia plus the Twomemo library have already been mentioned which use OMEMO:2. It seems that Siacs OMEMO is still the most widespread standard of OMEMO.

https://github.com/wstrm/omemo-utils are utilities for media sharing through OMEMO.

Verse is Lua module for OMEMO which uses Javascript. Couldn't find a Lua implementation without Javascript.

https://blog.jabberhead.tk/2018/09/07/future-of-omemo/ (2018) is a good read. It mentions Messaging Layer Security (MLS) as newer encryption system, but the last activity on that was in 2018.

For comparison to OMEMO, Matrix uses OLM. for its message encryption. https://github.com/wstrm/omemo-utils
 
Since 27 May 2023 Gajim upstream has 1.8.0 with integrated OMEMO (not as a dependency).
On 07 Aug 2023 Gajim was updated to 1.8.1.
Today in FreeBSD we have still a broken 1.3.3.

Those who need a quick solution may find 1.8.1 packages there:

Arch Linux - Package Search

archlinux.org archlinux.org


As those repositories are faster in responding to upstream changes it may be worth thinking about migrating.
FreeBSD is not the ultimate choice when it comes to communications. I.e. working and uptodate SIP and VoIP packages may be hard to find in FreeBSD.
 
thindil said:
MLS was accepted as an Internet standard this year: https://www.ietf.org/blog/mls-protocol-published/

So, maybe it will replace OMEMO in XMPP.
Click to expand...
https://www.rfc-editor.org/rfc/rfc9420.html the updated RFC for MLS (Messaging Layer Security protocol).

Looks like MLS is likely to replace OLM for Matrix as their group is mentioned there.

XMPP isn't at https://www.ietf.org/blog/support-for-mls-2023/. This means that Siacs OMEMO will be the most widespread until there's interest in importing MLS to XMPP, which may take a while.

The working group of MIMI (More Instant Messaging Interoperability; https://datatracker.ietf.org/group/mimi/about/) sounds great. MIMI is about Interoperability, with MLS as one component of that.
Numerous prior attempts have been made to address messaging interoperability, including the IETF's extensive prior work on XMPP, SIP/SIMPLE, and their related messaging formats. The MIMI working group will draw lessons from these prior attempts, seek to avoid re-hashing old debates, and will focus on the minimal standards suite necessary to facilitate interoperability given the feature set of modern messaging applications.
Click to expand...
MIMI will communicate with related working groups as needed, including MLS, STIR, OAUTH, GNAP, and the W3C Verifiable Credentials WG.
Click to expand...
MIMI doesn't necessarily have focus on XMPP at this time, but will have a major influence on it.


Edits:
  • STIR (Secure Telephone Identity Revisted) - Correct verification of origin or prevent spoofing of SIP calls.
  • OAUTH and GNAP are for authentification credentials related to XML

Matrix and XMPP attempting to influence MIMI
XMPP and Matrix are trying to influence MIMI, at least for specifications not completed yet.
The Matrix protocol is said to be planning to support MLS for end-to-end encryption. Interestingly, existing protocols such as XMPP, Matrix, etc. seem to be trying to partially occupy the yet to be defined components of MIMI, so that they can fit in their technology in MIMI. Even if no release dates are available, all that shows the interest in and importance of MIMI.
Click to expand...
teamwire.eu

MIMI with MLS - the new standard of messaging apps?

A new standard called MIMI with MLS for instant messaging app interoperability is currently being discussed. Learn more here!
teamwire.eu teamwire.eu

Before MIMI, Matrix wanted to become an IETF specification. Later, Matrix wanted MIMI to adopt itself. Then, Matrix settled on trying to influence the message format (https://datatracker.ietf.org/doc/draft-ralston-mimi-matrix-message-format/) and transport layer (https://datatracker.ietf.org/doc/draft-ralston-mimi-linearized-matrix/). Matrix wants to have some presence in a current IETF standard and perhaps some interoperability, even if it means evolving Matrix itself. https://matrix.org/blog/2022/12/25/the-matrix-holiday-update-2022/


I wonder if XMPP and Matrix will evolve in a way for common simple standards and if they will bridge to MIMI in that way.
 
Update: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274490. Different bug report on attempting to import Gajim 1.8.1 for reasons of OMEMO encryption. In progress.

Perhaps it will make older bug reports on Gajim, which are for previous versions, irrelevant.


XMPP with Pidgin using Lurch has worked recently with mixed results with OMEMO. It's kind of difficult to use on it, and lacks controls for it and difficult to know when it's on. Doesn't work all the way for different testing accounts and peers on the list, and difficult to know why.
 
For the record: gajim 1.8.x requires python >= 3.10, so we have to wait until default python version changes in ports. The update also require ports that are not present in the tree at the moment, like omemo-dr (gajim's python-axolotl fork) for integrated omemo encryption.
Click to expand...

274490 – net-im/gajim: update to 1.8.4 reason: OMEMO is broken

bugs.freebsd.org bugs.freebsd.org

Question: We do have python3.10 in the ports. Why can't we have a py310-port fixing the problem? Are ports forbidden to have other than default Python version even when the py39-version is broken?
 
getopt said:

274490 – net-im/gajim: update to 1.8.4 reason: OMEMO is broken

bugs.freebsd.org bugs.freebsd.org

Question: We do have python3.10 in the ports. Why can't we have a py310-port fixing the problem? Are ports forbidden to have other than default Python version even when the py39-version is broken?
Click to expand...
Because it requires many other ports to update. I was trying to prepare an update for gajim, but if I remember correctly, it required to update other ports which don't have flavors and depends on the default Python version. And this caused other ports to break. 🤣
 
Folks forget the degraded py39-ports and the need of "maintainers". Just do it yourself.

I'm happily running Gajim 1.8.3 on FreeBSD with having installed by
Code: 
pip3.11 install -v --user gajim-1.8.3.tar.gz
and met all requirements before.
Of course you can use Python3.10 too, but 3.11 is faster and I had that already.

Enjoy!
 
That's a good outcome, maybe you're on to something related to improving the structure or way of use of Ports. Even ignoring the broken python version for one that works.

It seems there needs to be a standard hybrid system for Ports. I sort of get it, but don't fully get it. If that works well, it needs to become standard alongside FreeBSD Ports, with how to keep each part separate.

There has to be some kind of method, including making an improvement to Ports, where Python defaults to using that system, or Python is ported in a more natural way. I wish FreeBSD would outsource work for Python ports, since they're that important for current applications to run.

Maybe the port maintainer can take a cue from this. Above, it's written, that Gaijim requires Python version >3.10. In the past, we had several versions of a port, side by side, without them breaking ports or requiring other ports to be updated.
 
I've noticed that OMEMO on NetBSD's Pkgsrc uses Python 3.11: https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/chat/gajim-plugin-omemo/index.html. However, the version of Gajim is also stuck on 1.3: https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/chat/gajim/index.html. On Pkgsrc, gajim-plugin-omemo relies on Gajim 1.3 and Python 3.11. I have no way to know if it fully works, as we see something that's available in writing, and we've made past assumptions that something is or isn't available as working. (examples: that microboards used graphics that FreeBSD had drivers for, that OMEMO was available since more recent updates, someone assuming something worked when they didn't realize graphics processing wasn't mature on FreeBSD, etc etc)

Taking what's available on NetBSD, not knowing yet if that combination of programs works, what if Gajim 1.3 can work with an OMEMO version that uses Python 3.11 on FreeBSD. What if, Gajim can be kept as is on 1.3 on FreeBSD for the time being, then the Python OMEMO plugin use the later versions made for it go with a typical FreeBSD install, or if not possible, only install that plugin through the Python PIP method as mentioned above.

Edits:
I looked at it again, and their Gajim1.3 also uses Python3.11, so that may not work here.

Additionally, I've wondered about using Pkgsrc on FreeBSD, but then saw a thread that says it's not practical and hasn't been done. I thought there would be guidelines on it from Pkgsrc, but that doesn't exist either.
 
Updates
For OMEMO, PR 271876 is fixed, https://cgit.freebsd.org/ports/commit/?id=22e0a974790709a32f73c1f1d9c4f6666fa39cc4, The old OMEMO library of python-axolot was forked and replaced with security/py-omemo-dr. It still relies on Python 3.9 or Python39 dependencies.

For net-im/gajim, it doesn't work with the default version of Python, but comment says, not to wait for that to become default because that will be a while. It also says that Gajim can currently be used, but it didn't speciffy if that was with OMEMO, and how they used that, as the port hasn't been changed. PR 274490
 
You must log in or register to reply here.
Back
Top