This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
federation: refresh devices_list for users more frequently #5433
Labels
A-Device-List-Tracking
Telling clients about other devices. Often related to E2EE.
A-Federation
O-Uncommon
Most users are unlikely to come across this or unexpected workflow
S-Major
Major functionality / product severely impaired, no satisfactory workaround.
T-Enhancement
New features, changes in functionality, improvements in performance, or user-facing enhancements.
z-feature
(Deprecated Label)
z-p3
(Deprecated Label)
z-uisi
(Deprecated Label)
Description:
Let's take two homeservers
A.com
andB.com
. You've set upA.com
andB.com
and they are both federating with one another freely.At the moment if you (possibly accidentally) nuke your already-federated
A.com
server and want to rebuild it using the sameserver_name
things work mostly fine (B.com
seems to accept the new signing key of your server without much issue, and federated events betweenA.com
andB.com
work properly).However, one issue that occurs is that the cached device list of
A.com
's users onB.com
will persist (assuming that you've kept the same usernames on the new installation). Not only that, but because the database has been completely nuked,A.com
won't know that it needs to sendm.device_list_update
EDUs toB.com
. This results in E2EE over federation being basically broken permanently because users onB.com
won't negotiate new Megolm session keys (because they don't see the newA.com
devices and instead only see the ghost ones.Would it be acceptable to make synapse automatically do a hard refresh of the devices list of the users on a federated server if the signing key of the homeserver changes? This could be done lazily (effectively just remove the cached information about devices, and when a user requests it then we fetch it over federation). Is there any attack that I'm missing which much result if we make this a default feature?
Workaround
As a quick hack, it is possible to fix this using the manhole in synapse -- by sending a
m.device_list_update
EDU toB.com
which has a broken value ofprev_id
. According to the spec this causesB.com
to reset its cached device list:Manhole Script -- USE AT YOUR OWN RISK
The text was updated successfully, but these errors were encountered: