If an m.room.encryption event is redacted, we think the room is no longer encrypted

[ara4n]

No description provided.

[ghost]

Description

So, encryption appears disabled in direct chat between riot-web desktop app and riot-android if user of the riot-web desktop app accidentally redact the encryption event.

Steps to reproduce

1. redact the event about encryption in riot-web
2. restart riot-web

encryption will appear disabled on both devices and need to be enabled again in room settings

if riot-web user send some messages before encryption is turned on again there will be a notice that messages have not been sent

Version information

• OS: Debian

• Version: riot-web 0.9.7

• OS: Android

• Version: 0.6.9

[lampholder]

Thanks for the comprehensive report :)

I was able to reproduce this. Messages sent after encryption had been 'disabled' triggered the 'Some of your messages have not been sent.' warning, but clicking 'Resend all' doesn't work and displays the following on the console:

Error sending event Error: Room was previously configured to use encryption, but is no longer. Perhaps the homeserver is hiding the configuration event.

Reemabling encryption does indeed restore room functionality.

[rubo77]

Would the reaction disable encryption successfully?

Or is the room completely disjunctionally broken then?

[turt2live]

Worse now, it has a chance at causing damage to the user's stored syncs, requiring a completely new initial sync to recover, and potentially leaving the room.

[RyanMelenaNoesis]

Any workaround for this issue? I currently have a multiple direct message chats that I'm unable to send messages to via the Riot.im Windows desktop client because of this. Exact same error message in the Electron console:

Error sending event Error: Room was previously configured to use encryption, but is no longer. Perhaps the homeserver is hiding the configuration event.

There is a difference, however, in that my desktop client still shows the room as encrypted under settings.

[RyanMelenaNoesis]

Upon further investigation, I found that the content key of the m.room.encryption configuration was empty {} in the affected rooms. Manually editing the content key to:

{ "algorithm": "m.megolm.v1.aes-sha2" }

within Room DevTools corrected the issue.

[ShadowJonathan]

I don't believe this is actionable, because redacting state events will already cause a whole lot of other behaviour to go haywire, and element isn't able to compensate for it anyways.

I suggest this be fixed on the spec side, and not on element's side, as i believe it's a larger issue with 'redacting state events'.

[richvdh]

I think this was incorrectly transferred from element-web. It appears to be specifically talking about element-web. Other platforms have other implementations and different behaviour.

[richvdh]

Actually, I was unable to reproduce this on (legacy) element-web, and it will be fixed by element-hq/element-web#26108 for Element Web R.

All clients should keep a record of which rooms are encrypted, and ignore attempts to turn it off. If anyone can reproduce this behaviour, please file issues against the client concerned (with clear repro steps, unlike this issue).