pantalaimon: pantalaimon does not encrypt the forwarded messages anymore(?)

I have a client (matterbridge) that doesn’t support Matrix’ encryption, so I use pantalaimon as a good man in the middle that handles the encryption for me. (Awesome project btw!)

I am using version 0.10.1 (after running into #101). Now the forwarded messages are not encrypted anymore.

To Reproduce Steps to reproduce the behavior:

Start pantalaimon (config see below)
Start matterbridge (which sends unencrypted messages, and I verified that it actually uses pantalaimon instead of connecting to matrix.org directly, because 1. I didn’t upgrade matterbridge, it worked before, and so the behavior shouldn’t have changed; and 2. if I kill pantalaimon then matterbridge complains about connection errors and messages don’t arrive at matrix.org at all anymore.)
Cause a message to be sent through matterbridge→pantalaimon→matrix.org

Expected behavior pantalaimon encrypts the message. Screenshot from last friday when it worked:

Bildschirmfoto_2021-07-12_14-10-00

(as shown by Element)

Actual behavior pantalaimon does not encrypt the message, and instead seems to forward it raw. Screenshot from just now:

Bildschirmfoto_2021-07-12_14-10-27

(as shown by Element)

Setup:

OS: pantalaimon runs on Raspbian, I can access it via panctl.
Version: $ pantalaimon --version pantalaimon, version 0.10.1

(There isn’t really a smartphone or a browser involved, so I don’t know what I should supply here.)

pantalaimon.conf:

[Default]
LogLevel = Debug
SSL = True

[local-matrix]
Homeserver = https://matrix.org
ListenAddress = localhost
ListenPort = 20661
SSL = False
IgnoreVerification = False
UseKeyring = False
``

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 21

Most upvoted comments

However, as @begincalendar already pointed out, the issue will crop up for other users as well. Maybe it might help to have stricter requirements on matrix-nio then? Maybe something like Requires-Dist: matrix-nio[e2e] (<0.18,>=0.18)?

Yeah, that’s the plan. Once I merge #103 a release with a stricter nio version requirement will happen.

poljar on Jul 14, 2021

All done, if there’s something else feel free to reopen.

poljar on Jul 14, 2021

Did you also upgrade matrix-nio?

poljar on Jul 13, 2021

Right, the latest Pantalaimon allows matrix-nio < 0.19.0 and 0.18.0 fixes an issue with the sync.

Upgrading things should fix this problem at least for you.

poljar on Jul 13, 2021

You can probably check that using pip

pip list | grep nio

poljar on Jul 13, 2021

Any idea which nio version is being used? I wonder if the client sync is failing for the same reason as https://github.com/matrix-org/pantalaimon/issues/101 and thus client.rooms stays empty forever.

poljar on Jul 13, 2021

There are a couple of reasons why Pantalaimon might decide why it shouldn’t encrypt for a room, after all it shouldn’t encrypt if a room isn’t marked as encrypted.

For example:

The room isn’t considered to be in a joined state: https://github.com/matrix-org/pantalaimon/blob/master/pantalaimon/daemon.py#L901
The room isn’t considered to be encrypted: https://github.com/matrix-org/pantalaimon/blob/master/pantalaimon/daemon.py#L921
The event type doesn’t support encryption: https://github.com/matrix-org/pantalaimon/blob/master/pantalaimon/daemon.py#L910

Number 3 doesn’t seem to be relevant here.

Number 2 hinges on the fact that we receive a m.room.encryption state event, this event is stored and you’re not able to downgrade the encryption in a room.

Number 1 of course is mutable so this might be the first thing to check out, the state of the room is fetched every time you restart Pantalaimon, so it might start working again after a restart.

As it is, I can’t reproduce this while testing with Fractal, it might be some bridge specific issue.

poljar on Jul 13, 2021