As part of its NLNet grant, slidge had a security audit from the good folks over at Radically Open Security. The full report is available for download if you are interested in more details. Three moderate-severity issues were found, let's discuss them a bit, from trivial to hard-to-solve.

Vulnerabilities in dependencies

We did not have any automated scanning of dependencies for vulnerabilities. It turns out that our project management tool (uv) supports this via their (wait for it) uv audit command. This tool scans the uv.lock file and identifies which dependencies have known vulnerabilities. We added a CI jobs for slidge and matridge (and other slidge-based gateways via our copier template).

In fact, this uv.lock file is not a python packaging standard file and is only used:

• during development;
• for our containers tagged vX.X.X (not latest, not main, which are more bleeding edge).

Linux distributions typically package more up-to-date dependencies for their packages, and PyPI.org installs only use the (looser) version constraints defined in the pyproject.toml file. That said, pyproject.toml has pillow pinned at version 11, which is not maintained anymore. We this bumped a major version for this dependency, and it turned out there was absolutely no breaking for the basic stuff we were doing with it (mostly converting images for contacts', rooms' and participants' avatars.). Easy peasy!

Taking the gateway down was too easy for anyone

While this was specifically detected for matridge, this was a general slidge issue that was adressed by commit db7fe0c in slidge "core".

It was trivial for anyone ¹ to trigger a crash by providing an invalid Matrix server while registering to the gateway. When attempting to register to a slidge-based gateway, the gateway checks whether the given credentials are valid and raises an XMPPError with an informative message if this fails anyhow. The general design of this is OK, but shit happens, and uncaught exception can occur in there, which caused the whole process to crash.

The fix was rather trivial, we now catch any exception during registration, and if it is not an XMPPError we raise XMPPError("internal-server-error") from it. Given slixmpp design, this returns an error stanza to the JID whose credentials triggered an exception somehow, which is what the protocol dictates.

Unencrypted user credentials

Unlike the two previous issues, this is a tough one, and there is no easy fix in the foreseeable future.

Slidge gateways act as clients to the bridged network, and as such, they need to store some credentials, there is just no way around that. You should absolutely not use slidge-based gateways if you do not trust the administrator of the XMPP server and if you are concerned about your account being taken over by them. Ideally you should self-host your slidge gateways.

We already do our best to store the bare minimum, when it is possible we only store a revokable token of some sort, and not username/password paris — this is already the case for matridge. But we could do something slightly better and not store this token unencrypted in the slidge database, using a symmetric encryption scheme is the recommendation from Radically Open Security.

This type of encryption, in our specific case, only protects against a very narrow threat model: an attacker that manages to dump the database but not its encryption key; despite the encryption key and the database most likely being very close to each other (often on the same host). On top of that, a slidge-based gateway might use a library that stores credentials in its own database and that we have no control over, in this case this optional encryption at rest might have no upside at all.

For these reasons, we are in no rush, but a pull request has been opened, where anyone interested is invited to join the discussion that Hugo and I (nicoco) have started.