please rageshake from both sides when you get the chance

There should be a blank event tile at the bottom of the timeline that is actually the m.key.verification.cancel event. Could you paste the sender and (decrypted) source here please?

Also, it looks like the riot on the right isn't latest develop and/or doesn't have the cross signing flag enabled. You can do this by adding "feature_cross_signing": "enable" to the features key in the config.json.

rageshakes sent.

There should be a blank event tile at the bottom of the timeline

errr which timeline?

Also, it looks like the riot on the right isn't latest develop and/or doesn't have the cross signing flag enabled.

probably both. seems like there should be a different failure mode though?

errr which timeline?

rageshakes sent.

There should be a blank event tile at the bottom of the timeline

errr which timeline?

Sorry, the timeline of the DM where the request was sent.

Also, it looks like the riot on the right isn't latest develop and/or doesn't have the cross signing flag enabled.

probably both. seems like there should be a different failure mode though?

Indeed.

I added extra logging to see the {reason, code} of cancelling in the rageshakes, which has now been deployed to /develop. @richvdh, could you please repro it again with one of the clients being latest /develop and rageshake? Thanks!

Hmm, the rageshake doesn't contain the logging I added before. It does contain a line that the verification failed because a key mismatch ... which seems odd.

Could you please try to reproduce again with latest develop on both sides and feature_cross_signing enabled on both sides? If you can repro, please rageshake on both sides 🙏

I think the problem might be happening because one side isn't on develop (though the side that I sent the rageshake from should have been). I can try with develop on both sides, but no guarantee that will repro the problem.

well I tried, and got #12357 instead

oh wait, I need to set feature_cross_signing somewhere?

oh wait, I need to set feature_cross_signing somewhere?

Yeah. it's enabled by default on riot.im/develop, but follow these steps if you're hosting yourself: #12226 (comment)

new failure mode: apparently I'm being mitmed or something:

So, looking at the rageshakes, the verification is cancelled because while checking the MAC, there is a key mismatch. The ed25519 device key for device UX... is different on the device checking the MAC (OH...), namely cHDuL73yDdJBpfPLN3tVcMJSHkaerOFthIeMP//JhSk than device UX... sends for themselves, namely VazsJl37/bvHYNifBxlwzNB8V5EbKCLVjsxVYjRuwNE.

Rich mentioned something about this particular device being b0rked, it does seem so. When looking for the device key in question with /keys/query it returns the key the UX... device is sending. How did device OH... end up with a stale/wrong key for device UX...?

So, most likely scenario:

1. device UX... was running short on disk-space and the browser purged its device keys in indexeddb.
2. riot detected this and created new keys and uploaded them
3. device OH... somehow didn't update the keys after this ... looking into how this could happen.

Ok, apparently we don't persist device key changes, as they might as well have come from a MITM'ing HS admin...

https://github.com/matrix-org/matrix-js-sdk/blob/develop/src/crypto/DeviceList.js#L943

Hubert argues that we rather want to prevent keys rotating than accepting rotated keys. I guess one thing we can do to avoid this is request persistent storage to the browser so it becomes less likely it will evict our indexeddb. Only reason we haven't done so so far is that FF shows you a prompt, so we'd have to be careful about how and when we do that.

I guess one thing we can do to avoid this is request persistent storage to the browser so it becomes less likely it will evict our indexeddb. Only reason we haven't done so so far is that FF shows you a prompt, so we'd have to be careful about how and when we do that.

Definitely agreed that we should do something there. I have updated #9362 to track.

Apart from trying to prevent indexeddb getting evicted, we should also already detect this case since matrix-org/matrix-react-sdk#2841, and show a dialog that forces a logout. Somehow that didn't happen here 🤔

All rageshakes for this issue in #10186 do seem to have the dialog appear for them, so I wonder if this could be a case where the key got rotated before this mitigation was in place (1 Apr 2019)?

Confirmed that the session that rotated keys is "years rather than months", so closing this as matrix-org/matrix-react-sdk#2841 prevents this for sessions not as old.

For sessions like this, one needs to log out and log in again. Then verification should work.

this is still an issue even on new sessions.

Closing this as the cause is not a rotated device key as before. I've created #13105 instead.