E2EE disabling plugin for Synapse

Fixes https://github.com/digitalentity/matrix_encryption_disabler/issues/3

This now works similar to https://github.com/fhirfactory/pegacorn-communicate-roomserver/pull/7, but still keeps encryption from being enabled from the start during room creation and filters the encryption events just to be safe.

If federated servers and clients respect permissions room encryption should never be enabled even if the room is federated.

@spantaleev you might want to test this change and make sure it works with your ansible playbooks (no reason why it shouldn't though).

Addresses some of the #5:

• Adds a configuration setting patch_power_levels (default disabled)
• Fixes the docs mentioning the option, how it works and why it may be dangerous
• Patch the event instead of owerwriting it if already present

Looking at the filtering source code, checking is done against the room id (e.g. !room:example.org), not against the address of the room (#room:example.org). It works for rooms without address aliases.

Can this module be ported to the new Synapse Module API: https://matrix-org.github.io/synapse/v1.52/modules/index.html

People will then be able to register it under modules in homeserver.yaml, and not under third_party_event_rules.

I'd like to add support for this to matrix-docker-ansible-deploy and it'd be much easier if we can just inject it into the modules list, as opposed to defining third_party_event_rules which only seems to support just one filtering module.

Scenario:

• Server 1: cleartext.info with this plugin installed and configured. Room !whatever:cleartext.info is created by @user1:cleartext.info
• Server 2: paranoid.org without this plugin. User @user2:paranoid.org is participating in the room and is made admin. This can happen automatically if a room is a DM.

User @user2:paranoid.org sets m.room.encryption without any restriction.

Server cleartext.info will reject the m.room.encryption event during federation sync.

Room is in inconsistent state. Users of the server cleartext.info are unaware that the room is now encrypted and can't sync the keys and read the encrypted messages.

This can be worked around by patching on_room_creation further and modifying m.room.power_levels to make the power level for m.room.encryption event higher than admin (i.e. 101), but I'm not sure if that's possible during room creation - we may have to craft the entire m.room.power_levels event including the room membership.

First than anything thank you for your work, I have a lot of time searching for something like this.

I already have my matrix-synapse server up and running, I want to install this module but documentation about pluggable modules is limited or I don't understand yet. Inicially, how can I install the .py file before I can edit the homeserver.yaml? I tried everything but cannot install (I'm really new with python packages, sorry) multiple errors with pip like "cannot import module_api from synapse" and others. Please explain like I'm five, your work could save many lives in my organization.

Thanks.

Edit: I already installed the python plugin. but now I can't make it work in the yaml file.

This is how it looks but it give me errors everytime

Fixes https://github.com/digitalentity/matrix_encryption_disabler/issues/7

This module quickly grew from a pet personal enhancement for Synapse into a bigger thing which has some users. Making it a proper Python module became important at this point.

Does Synapse not validate these power level values? Is 150 a valid value? The m.room.power_levels description in the Matrix 1.2 spec does not seem to explicitly state that you can't use a value higher than 100.

In practice, it seems like you've tested it and Synapse and the clients you've tested don't break, at least not yet.

Still, it seems a little dangerous to use such values. Any homeserver that gets involved with this room over federation may encounter trouble. Even Synapse itself may reject this unusual value if it encounters it over federation (not tested, but it's a reasonable suspicion).

So I think that this feature is a little dangerous to have, especially when enabled by default.

It may make sense to:

• try and clear up what the spec really says
  • [ ] can one go higher than 100?
  • [ ] should the next spec release make that explicit, so that other homeserver and client developers will be made aware of it?
• test if such rooms can federate:
  • [x] most importantly with Synapse
  • [ ] Dendrite
  • [ ] Conduit
• test other clients:
  • [x] I assume that at least Element (on which platform?) doesn't break
  • [x] and you've probably tested Fluffychat yourself
  • [ ] should some other clients be tested?
• consider whether this should be "on by default and always". It creates a non-standard room that has potential to break and that cannot be fixed (I assume you can't bring m.room.encryption down to 100 or lower, once you've set it to a value than your own power level)
  • [x] a configuration setting may make sense
  • [x] disabling it by default may make sense
  • [x] consider mentioning in the docs (or configuration setting information, if a configuration setting is introduced) that power levels may be replaced with a borked up non-standard risky value
  • [x] .. and that all rooms created while matrix_encyption_disabler is active are forever prevented from becoming encrypted

Originally posted by @spantaleev in https://github.com/digitalentity/matrix_encryption_disabler/issues/4#issuecomment-1037894963