Repository navigation
Drop federation device list updates from non-compliant user IDs - #20115
Merged
sandhose merged 5 commits intoSep 16, 2026
Merged
Conversation
…uld be dropped Per https://spec.matrix.org/v1.14/appendices/#historical-user-ids, servers SHOULD NOT forward non-compliant (grandfathered historical) user IDs to clients outside the context of an event; the spec gives dropping their device list updates as the example.
Per https://spec.matrix.org/v1.14/appendices/#historical-user-ids, servers SHOULD NOT forward non-compliant (grandfathered historical) user IDs to clients when referenced outside the context of an event. Device list updates from such user IDs previously surfaced to clients via /sync's device_lists.changed; drop the EDU on arrival instead.
anoadragon453
approved these changes
Sep 15, 2026
sandhose
enabled auto-merge (squash)
September 16, 2026 09:06
HarisDotParis
pushed a commit
to HarisDotParis/synapse
that referenced
this pull request
Sep 16, 2026
…ment-hq#20115) This partially fixes the bug element-hq#20116 Device list update EDUs from non-compliant (grandfathered historical) user IDs are currently accepted over federation, stored, and surfaced to clients in `/sync`'s `device_lists.changed` array. > For current room versions, servers must still accept events using such user IDs over federation; however they SHOULD NOT forward such user IDs to clients when referenced outside the context of an event. For example, device list updates from non-compliant user IDs would be dropped by the receiving server. > > -- [Matrix spec](https://spec.matrix.org/v1.14/appendices/#historical-user-ids), clarified in Matrix v1.14 by [matrix-spec#1506](matrix-org/matrix-spec#1506) ### Problem Example A remote server sends an `m.device_list_update` EDU for `@héllo:remote.example` (non-ASCII localpart, outside the compliant U+0021–U+007E range). Synapse: - accepts and processes the update (resyncing the user's device list if needed) - stores it in the remote device list cache - forwards `@héllo:remote.example` to local clients via `device_lists.changed` in `/sync` (**the leak** — a non-compliant user ID referenced outside event context) --- ### Pull Request Checklist <!-- Please read https://element-hq.github.io/synapse/latest/development/contributing_guide.html before submitting your pull request --> * [x] Pull request is based on the develop branch * [x] Pull request includes a [changelog file](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#changelog). The entry should: - Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from `EventStore` to `EventWorkerStore`.". - Use markdown where necessary, mostly for `code blocks`. - End with either a period (.) or an exclamation mark (!). - Start with a capital letter. - Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry. * [x] [Code style](https://element-hq.github.io/synapse/latest/code_style.html) is correct (run the [linters](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#run-the-linters))
3 tasks done
reivilibre
pushed a commit
that referenced
this pull request
Oct 13, 2026
Closes #20116 > [!NOTE] > This PR Follows #20115 which already implemented this for `m.device_list_update` > User IDs with localparts containing characters outside the range U+0021 to U+007E, or with > an empty localpart, are considered non-compliant. For current room versions, servers must > still accept events using such user IDs over federation; however they SHOULD NOT forward > such user IDs to clients when referenced outside the context of an event. For example, > device list updates from non-compliant user IDs would be dropped by the receiving server. > > — [Spec 1.19](https://spec.matrix.org/v1.19/appendices/#historical-user-ids) This PR prevents from forwarding non compliant user ids for the following events: - `m.signing_key_update` 8c3c35e - `m.presence` 26a8dfe - `m.typing` 1110cf2 - `m.receipt` 9e2da8b - `m.direct_to_device` 9541232
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This partially fixes the bug #20116
Device list update EDUs from non-compliant (grandfathered historical) user IDs are currently accepted over federation, stored, and surfaced to clients in
/sync'sdevice_lists.changedarray.Problem Example
A remote server sends an
m.device_list_updateEDU for@héllo:remote.example(non-ASCII localpart, outside the compliant U+0021–U+007E range). Synapse:@héllo:remote.exampleto local clients viadevice_lists.changedin/sync(the leak — a non-compliant user ID referenced outside event context)Pull Request Checklist
EventStoretoEventWorkerStore.".code blocks.