[e2e] Corrupted OlmSessions

[richvdh]

The client can encrypt a message with an OlmSession, and send it, without having persisted the OlmSession. If the OlmSession is not persisted before the app is terminated, then the app will be unable to decrypt subsequent messages sent on the session.

The symptoms of this are that the android user cannot decrypt messages sent by certain senders; the logs contain decryptMessageJni(): failure - olm_decrypt Msg=BAD_MESSAGE_MAC.

[richvdh]

Once we fix this, we're probably going to have to force the user to log in again with a new device. So we probably need to implement backup-your-megolm-sessions (the android equivalent of element-hq/element-web#2108), and then, when the user upgrades to a version with a fix to this in place, prompt them to back up their sessions and log them out.

[ylecollen]

The android client saves the data synchronously by now.
I did not implement "backup-your-megolm-sessions" feature.

[richvdh]

@ylecollen: how can we get this finished? It sounds like the root cause is fixed, but we may still have users with corrupted olm sessions. One solution might be to force the user to register a new device, but copy the megolm data over?

[ylecollen]

I could close this issue as you said because it should be fixed by now.
I prefer that the users report a bug report and we advice them to re-register to fix the issue (we're going to add a dialog when logging out to advice the users to backup his/her e2e keys).
It seems better to do it on demands else many users will complain of this unexpected registration.

Does it make sense for you ?

[richvdh]

well, the problem is that it's time-consuming to go through the logs from both sides to determine if this might have been the problem, and there is no sure way to tell from the logs that this was the problem. Furthermore, because the olm sessions never expire, and we have no way to tell how old they are, users could still be suffering from this bug in 5 years time, because they used the session with an old version of the android client. It almost feels like it's better to make a clean break now.

As a compromise, maybe we could record the android client version when the user logged in (ie, when their e2e state was first used). Then we could come back to this in a few months and log out any users who still have very old e2e sessions?

[ylecollen]

[ylecollen]

@richvdh
The version is now stored. The android client can now detect the application update and perform some dedicated actions.

[ara4n]

note to reader: while the root cause is fixed here, we may still be seeing UISIs out there due to people with old corrupt sessions