Repository navigation
Famedly release v1.164 - #303
Merged
Merged
Conversation
…20312) Motivated by work on MSC4354, because the sticky events MSC specs that `received_ts` is used to calculate the start of an event's stickiness. (It would therefore be convenient to have it available as part of event metadata, so an event can expose a cheap helper method to check if it is sticky.) This commit adds `received_ts` into the `event.internal_metadata` struct, alongside `stream_ordering`. I conceptually treat it as a sibling to `stream_ordering` and populate it in all the same places where `stream_ordering` is populated. Because this needs `received_ts` to be added to the HTTP replication response for event persistence, I also add a temporary compatibility measure that keeps rolling worker upgrades working during this transition. I intend to remove the compatibility code in the next release. I have manually tested that ``` SYNAPSE_POSTGRES=1 SYNAPSE_POSTGRES_USER=postgres SYNAPSE_POSTGRES_HOST=localhost SYNAPSE_POSTGRES_PASSWORD=postgres poetry run trial -j 6 tests.replication.test_sharded_event_persister ``` fails only when both the compatibility code is removed and the `"received_ts"` key is commented out in the response (to omit it). The compatibility code causes the test to pass even when `"received_ts"` is commented out. --------- Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
This is a prerequisite to being able to add caching on the Rust side.
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
…s not advanced. (#20316) In a similar vein to #20315, this attempts to speed up Synapse when delayed events aren't in use. Here we skip doing any work if the room event stream has not advanced.
… how the server tracks them. (#20324) Part of: MSC4354 (Experimental Feature tracking issue #19409) Follows: #20312 (which plumbs `received_ts` into the `Event` struct, allowing us to calculate this correctly and sanely) - When writing to `sticky_events`, we now use the `received_ts` stamped onto the event to calculate the expiry, rather than taking a second clock reading. - When emitting the `unsigned.sticky_duration_remaining_ms` (currently called `unsigned.msc4354_sticky_duration_ttl_ms`) field, we now also use the `received_ts` as a clamp on the start of the stickiness, causing us to calculate the same expiry timestamp as the one saved to `sticky_events` (**This is a bugfix, as previously we weren't using `received_ts` here like the MSC requires.**) - The calculation of the expiry is centralised into the `Event` struct, which I hope you'll agree is a huge sanity improvement. - We now systematically prevent spammy or rejected events from counting as sticky. --------- Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org> Co-authored-by: Erik Johnston <erikj@element.io>
Co-authored-by: Andrew Morgan <andrew@amorgan.xyz> Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Use a new, dedicated endpoint for scheduling delayed events. This should deprecate the `delay` query parameter on the `/send` and `/state` endpoints. Co-authored-by: Paul Chobert <paul@chobert.fr> Co-authored-by: Eric Eastwood <erice@element.io>
…nts (#20273) ESS deployments of MatrixRTC are going to run `lk-jwt-service` as an application service so that it can manage delayed events. However, setting up an application service is particularly inefficient, as Synapse iterates through all the events of the rooms it covers since their creation. When an application service is configured with `url: null`, there is no need to traverse all the events for it, so we can set up such application services much faster without having to decide what to do for other application services. Discussions about those are still open: element-hq/synapse#11629 (see also matrix-org/synapse#1834). ### 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))
TLDR: `PUT` on a server-default push rule now applies the same existence check that `GET` already does. A rule that is not served cannot be modified. Synapse ships some server-default push rules behind experimental feature flags, so the set of server-default rules a user has depends on the server's configuration. Most flags add rules that only exist while the flag is on. [MSC4210](matrix-org/matrix-spec-proposals#4210) works the other way: it removes the three legacy mention rules while its flag is on. The flags that change the set are: - `msc1767_enabled`: [MSC1767](matrix-org/matrix-spec-proposals#1767) extensible events rules - `msc3381_polls_enabled`: [MSC3381](matrix-org/matrix-spec-proposals#3381) poll rules - `msc3664_enabled`: [MSC3664](matrix-org/matrix-spec-proposals#3664) reply rule - `msc4028_push_encrypted_events`: [MSC4028](matrix-org/matrix-spec-proposals#4028) encrypted event rule - `msc4306_enabled`: [MSC4306](matrix-org/matrix-spec-proposals#4306) thread subscription rules - `msc4210_enabled`: removes `.m.rule.contains_display_name`, `.m.rule.contains_user_name` and `.m.rule.roomnotif` `GET /pushrules/` only lists the rules that exist for that configuration. `GET` on a single rule that is not in the set returns `404 M_NOT_FOUND`. The same set is used to evaluate notifications, and to build the `m.push_rules` account data in `/sync`. `PUT .../enabled` and `PUT .../actions` did not use that set. They accepted any rule ID that Synapse knows about, whether or not the server currently serves it. Clients could modify a rule the server had just said did not exist. The request returned `200`, the change was stored, and it was then ignored. Both endpoints now return `404 M_NOT_FOUND` for such a rule, as [the spec requires](https://spec.matrix.org/v1.19/client-server-api/#put_matrixclientv3pushrulesglobalkindruleidenabled) for a rule that does not exist. Before (`msc4210_enabled: true`): ``` GET /_matrix/client/v3/pushrules/global/override/.m.rule.roomnotif 404 {"errcode": "M_NOT_FOUND", "error": "..."} PUT /_matrix/client/v3/pushrules/global/override/.m.rule.roomnotif/enabled {"enabled": false} 200 {} ``` After: ``` GET /_matrix/client/v3/pushrules/global/override/.m.rule.roomnotif 404 {"errcode": "M_NOT_FOUND", "error": "..."} PUT /_matrix/client/v3/pushrules/global/override/.m.rule.roomnotif/enabled {"enabled": false} 404 {"errcode": "M_NOT_FOUND", "error": "Unknown rule"} ``` This is a no-op for default configurations. All of these flags are off by default, and rules that are served are still modifiable as before.
Part of #19415 (Support Matrix 1.17). Companion test PRs: - Complement: matrix-org/complement#920 - Sytest: matrix-org/sytest#1430 **What this does:** `experimental_features.msc4210_enabled` default value changed `true` ([MSC4210](matrix-org/matrix-spec-proposals#4210)). The rest of the changes is fixing the tests, making sure test relying en mentions sends the proper `m.mentions` attribute. ## Migration plan Element Web has been writing both rule sets together since September 2023 ([matrix-react-sdk#11667](matrix-org/matrix-react-sdk#11667), [element-web@0d367a7c7e](element-hq/element-web@0d367a7c7e)), so for its users `.m.rule.is_user_mention` and `.m.rule.is_room_mention` already carry the same customisations as the legacy rules. <strike>For everyone else, #20215 adds a background update that migrates the overrides on the legacy rules to the intentional ones.</strike> ## Opt-out ```yaml experimental_features: msc4210_enabled: false ``` --- ### 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))
… after persistence. (#20323) Part of: MSC4354 Part of: #19641 Follows: #20232 (redacted before persistence), #20322 (redacted during persistence) Original commit schedule, with full messages: - Add tests for redaction of Sticky Events - Add `delete_sticky_events_txn` - Remove stickiness from validly redacted events at persistence ### Dev notes Overview: - [`#20232`](element-hq/synapse#20232) (redacted before persistence) - [`#20322`](element-hq/synapse#20322) (redacted during persistence) - [`#20323`](element-hq/synapse#20323) (redacted after persistence) --------- Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
Several clients, including Element Web/Desktop and Element X, have already implemented [MSC4426](matrix-org/matrix-spec-proposals#4426) User Status profile fields. However, we have only implemented sending profile fields down sync for local users ([MSC4429](https://github.com/matrix-org/matrix-spec-proposals/pull/4429)/[MSC4262](https://github.com/matrix-org/matrix-spec-proposals/pull/4262)), since federation support for pushing profile field updates from server to server has not yet been implemented ([MSC4259](matrix-org/matrix-spec-proposals#4259)). This has created user confusion. The before mentioned clients use the profile and/or profile field fetch endpoints to fetch missing profile information, regardless of the user being local or remote. Since the sync response isn't delivering these profiles, the client does a fallback fetch, causing a one time update of the profile information over federation. This causes stale data to be cached in the client for the remote user, which in the case of EW for example is never cleared. This filtering should be temporary until MSC4259 is implemented and the remote profile data also syncs via the profile update stream to clients. I suggest making this not configurable so we don't have to maintain a configuration property, as hopefully this would only be a case for a few months at most. ### 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)) --------- Co-authored-by: Eric Eastwood <madlittlemods@gmail.com>
…3) (#20081) Fixes element-hq/synapse#18793 When the last local user leaves a room, Synapse clears `current_state_events` and writes `null` `event_id` entries into the `current_state_delta_stream`. The incremental sync code for MSC4222's state_after skipped those `null` deltas entirely, and `get_current_state_ids` also returned nothing (table already cleared). Result: clients using `state_after` never learned about the leave. Fix by falling back to state groups (which are preserved) to look up the actual state at `end_token` for any cleared state keys. ### Pull Request Checklist * [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)) --------- Co-authored-by: Paul Chobert <paul@chobert.fr> Co-authored-by: Quentin Gliech <quenting@element.io> Co-authored-by: Eric Eastwood <madlittlemods@gmail.com>
…n `/sync` (#20170) Part of #19414 (Support Matrix 1.16).⚠️ Before merging, wait for the following PRs to be merged first: - element-hq/synapse#20081 - element-hq/synapse#20169 - element-hq/synapse#20171 --- Since Matrix 1.16, the [spec](https://spec.matrix.org/v1.19/client-server-api/#get_matrixclientv3sync) defines the stable identifiers for [MSC4222](matrix-org/matrix-spec-proposals#4222): the `use_state_after` query parameter on `GET /_matrix/client/v3/sync`, and the `state_after` room response field: > **`use_state_after`** — `boolean` — Controls whether to receive state changes between the previous sync and the start of the timeline, or between the previous sync and the end of the timeline. If this is set to `true`, servers MUST respond with the state between the previous sync and the end of the timeline in `state_after` and MUST omit `state`. […] > > **`state_after`** — […] Required if `use_state_after` was set to true in the request, even if it is empty. Added in `v1.16` > > — [Matrix Spec](https://spec.matrix.org/v1.19/client-server-api/#get_matrixclientv3sync) Synapse so far only implemented the unstable identifiers (`org.matrix.msc4222.use_state_after` / `org.matrix.msc4222.state_after`), gated behind the `msc4222_enabled` experimental flag and the per-user experimental features admin API. This PR: - accepts the stable `use_state_after` query parameter, unconditionally, and responds with the stable `state_after` field. The unstable query parameter is kept for a transition period; clients opting in with it get the unstable response field name back, so unstable-era clients see an unchanged wire format. If both parameters are set, the stable one wins. - removes the `msc4222_enabled` experimental flag and the `msc4222` per-user feature from the experimental features admin API, since the behaviour is no longer gated. ### 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)) --------- Co-authored-by: Eric Eastwood <madlittlemods@gmail.com>
Synapse now implements every item in the Matrix v1.16 changelog (all ticked in #19414), so it can advertise `v1.16`. Closes #19414.
Synapse now implements every item in the Matrix v1.17 changelog #19415, it can advertise `v1.17`. Closes #19415.
…#20321)
Fixes #20309.
For endpoints that validate the request body with Pydantic, a validation
failure put Pydantic's raw verbose error text into the `error` field of
the standard error response, e.g.:
```json
{
"errcode": "M_MISSING_PARAM",
"error": "1 validation error for PutBody\\nroom_id\\n Field required [type=missing, input_value={}, input_type=dict]\\n For further information visit https://errors.pydantic.dev/2.12/v/missing"
}
```
This leaks internal details clients cannot act upon (model class names,
raw input values, pydantic.dev URLs). This PR adds a
`_format_pydantic_error` helper in `synapse/http/servlet.py` that builds
a short client-friendly message from the structured
`ValidationError.errors()` data instead of `str(e)`:
- `{}` against a model requiring `room_id` -> `Missing required field
'room_id'.`
- `{"room_id": 123}` -> `'room_id': Input should be a valid string.`
- nested models use dotted paths, e.g. `Missing required field
'put.room_id'.`
- multiple errors are joined: `Missing required field 'name'; Missing
required field 'put'.`
The `errcode` selection logic (`M_MISSING_PARAM` / `M_INVALID_PARAM` /
`M_BAD_JSON`) is unchanged.
…client-server endpoints. (#20295) Part of: MSC4354 (Experimental Feature tracking issue: element-hq/synapse#19409) --------- Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
… the same persistence batch. (#20322) Part of: MSC4354 Part of: #19641 Follows: #20232 (which applies already-persisted redactions to Sticky Events being persisted) In some cases we batch events together during persistence. If one of the events in the batch is a redaction of another event, we should apply it, which provides the same benefit as #20232 (namely: we avoid potentially dodgy event content being persisted & the event naturally loses its stickiness so is not written to `sticky_events`) --------- Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
## Summary - default `request_token_inhibit_3pid_errors` to `true` to prevent account enumeration - document the new default and the explicit opt-out - add an upgrade note and regression coverage for the default Fixes #18415.
Bumps [rustls](https://github.com/rustls/rustls) from 0.23.31 to 0.23.45. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rustls/rustls/commit/2976d90fd1c2db6b518700dd101b714069cfcb17"><code>2976d90</code></a> Prepare 0.23.45</li> <li><a href="https://github.com/rustls/rustls/commit/f9d4ee92b20da535ef5982ffcaf6f62385f79641"><code>f9d4ee9</code></a> Handshake "alignment" check covers previously-received messages</li> <li><a href="https://github.com/rustls/rustls/commit/c4e92e8c9ee29ca3f552d4938efa73680c179179"><code>c4e92e8</code></a> Keep data needed for HRR processing together</li> <li><a href="https://github.com/rustls/rustls/commit/e553a7a70f99cad4722f06b32cc37857008a7d3f"><code>e553a7a</code></a> server: TLS1.2 is not available after a HRR</li> <li><a href="https://github.com/rustls/rustls/commit/5dff9da73798253d8d35909dd8548db522cd973c"><code>5dff9da</code></a> Test whether server negotiates TLS1.2 after HRR</li> <li><a href="https://github.com/rustls/rustls/commit/185a063b5fe1e9698c589d8be6a83d67224b95a1"><code>185a063</code></a> reject a second ClientHello that changes the cipher suite</li> <li><a href="https://github.com/rustls/rustls/commit/9fafe6dd0c15ea6e47399e94b2c6b647861f874b"><code>9fafe6d</code></a> reject a second ClientHello that drops pre_shared_key</li> <li><a href="https://github.com/rustls/rustls/commit/1b42c5f78e8e826d6afa72ce0ead3e3a4e624d79"><code>1b42c5f</code></a> providers: zeroize private key DER</li> <li><a href="https://github.com/rustls/rustls/commit/64ad386785c718c74262b79e6893813db381adfe"><code>64ad386</code></a> Bump version to 0.23.44</li> <li><a href="https://github.com/rustls/rustls/commit/1efbf662ed79d1392c542c0822805a818d232ac0"><code>1efbf66</code></a> bogo: remove PostQuantum setup</li> <li>Additional commits viewable in <a href="https://github.com/rustls/rustls/compare/v/0.23.31...v/0.23.45">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/element-hq/synapse/network/alerts). </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
No longer cancel a user's delayed state events by a more recent state event sent from a different user. This behaviour has been delegated to an "alternative" in the delayed event MSC for some time now, and is not known to be used by any module other than experimental iterations of MatrixRTC. See also: matrix-org/complement#845 Opens: element-hq/synapse#20311 --------- Co-authored-by: Olivier 'reivilibre' <olivier@librepush.net> Co-authored-by: Paul Chobert <paul@chobert.fr>
…20315) This speeds up the /createRoom calls a tiny bit by not checking the senders push rules. This helps speed up a lot of test runs in Element Web which runs a lot of tests in one-person rooms (and creates a heck of a lot of rooms)
For element-hq/synapse#19719 MSC4452 is now merged, so the stable capability can be made visible. I've kept in the unstable flag in order to transition away at a later date. ### Pull Request Checklist <!-- Please read https://element-hq.github.io/synapse/latest/development/contributing_guide.html before submitting your pull request --> * [ ] Pull request is based on the develop branch * [ ] 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. * [ ] [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))
These things are not needed now that MSC2965 has stabilised. In any case, they should never have been exposed without a config flag in the first place.
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` 8c3c35e95d - `m.presence` 26a8dfe862 - `m.typing` 1110cf2d73 - `m.receipt` 9e2da8b0a6 - `m.direct_to_device` 9541232a30
…(#20069) Gets one step further in the job started by matrix-org/synapse#12893 Part of: element-hq/synapse#20026 ## Manual testing strategy Unfortunately it's quite difficult to actually trigger this. You need to: - check out an old full_schema, e.g. 54 which was present when `v1.62.0` was released - remove the version 72 `full_schema`, as it already has the background update applied - remove some deltas that are broken when upgrading across such a large version gap (!) element-hq/synapse#20070 - then run any trial test with Postgres enabled to prove that the database schema applies ``` git checkout v1.62.0 -- synapse/storage/schema/state/full_schemas/54 git checkout v1.62.0 -- synapse/storage/schema/main/full_schemas/54 git checkout v1.62.0 -- synapse/storage/schema/common/full_schemas/54 rm -r synapse/storage/schema/*/full_schemas/72 rm synapse/storage/schema/main/delta/58/10_pushrules_enabled_delete_obsolete.sql rm synapse/storage/schema/main/delta/79/04_mitigate_stream_ordering_update_race.py rm synapse/storage/schema/main/delta/56/redaction_censor3_fix_update.sql.postgres rm synapse/storage/schema/main/delta/60/01recreate_stream_ordering.sql.postgres SYNAPSE_TEST_LOG_LEVEL=DEBUG SYNAPSE_POSTGRES=1 poetry run trial tests.handlers.test_sliding_sync.ComputeInterestedRoomsTestCase_new.test_no_joins_after_to_token ``` As light validation, I purposefully inserted a SQL error into the query to check that it is caught by the above testing strategy. --------- Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
…w guests (#20257)
Updates `certifi` to 2026.10.19 to address [GHSA-6q48-6c7w-9gw2](GHSA-6q48-6c7w-9gw2). certifi before 2026.10.19 bundles `emSign ECC Root CA - G3`, which chains to the compromised eMudhra intermediate CAs. This only affects TLS connections made by the Sentry SDK when `sentry` is configured, as `sentry_sdk`'s transport is the only runtime user of certifi. Federation and Synapse's other outbound HTTP requests use the system trust store via `platformTrust()`. Python advisory: https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576 --------- Signed-off-by: Bardi Harborow <bardi@bardiharborow.com>
…(#20392) `rustls-webpki` releasenotes: https://github.com/rustls/webpki/releases/tag/v%2F0.103.16 Part of element-hq/backend-internal#306 Related to element-hq/synapse#20387 We already use the system CA store when making requests in our Rust code (using the [`rustls-tls-native-roots`](https://github.com/element-hq/synapse/blob/7c85c80033ea5c3ca3851f3dab1d0397b94d5183/rust/Cargo.toml#L61) ([docs](https://docs.rs/reqwest/0.12.28/reqwest/#optional-features)) feature with `reqwest`). For a system that already has a patched system CA store, bumping `rustls-webpki` is simply extra protection as it actively blocks those untrusted certs. For an unpatched system CA store, this provides a stop-gap. ### Dev notes ```shell $ cargo tree --invert rustls-webpki rustls-webpki v0.103.16 └── rustls v0.23.45 ├── hyper-rustls v0.27.7 │ └── reqwest v0.12.28 │ └── synapse v0.1.0 (/home/eric/Documents/github/element/synapse/rust) ├── reqwest v0.12.28 (*) └── tokio-rustls v0.26.2 ├── hyper-rustls v0.27.7 (*) └── reqwest v0.12.28 (*) ```
…pport allows - Synapse 1.164.x (#20399) The problem is that while `pillow@12.3.0` supports Python >= 3.10, `pillow@13.0.0` only supports Python > 3.11, and we haven't dropped support for Python 3.10 yet (tracked by element-hq/synapse#20041). `pillow@13.0.0` includes some important security fixes: https://pillow.readthedocs.io/en/stable/releasenotes/13.0.0.html ### How was this change made? 1. `poetry update pillow` 1. Manually change the `"pillow"` `markers` in `poetry.lock` to split at Python 3.11 instead of 3.14 Please note this is not a durable change. `poetry` will try to revert this any time we try to make a change (requires diligence to make sure we keep changing it back). This maintenance burden will disappear once we drop Python 3.10 support (tracked by element-hq/synapse#20041). ### Alternatives If we were up for updating the minimum version of `pillow` in `pyproject.toml`, we could do something like the following which would resolve in `poetry.lock` durably how we want, `pyproject.toml` ``` # Pillow 13 dropped Python 3.10 but has security fixes. Split so 3.11+ can pick up # the security fixes. # # FIXME: Remove the split once we drop Python 3.10 support. "Pillow>=10.0.1,<13; python_version < '3.11'", "Pillow>=13.0.0; python_version >= '3.11'", ``` It looks like we [previously bumped](https://github.com/element-hq/synapse/blob/4853cd4238e100183fd7b0852ddf3e8eef894658/pyproject.toml#L54-L56) the minimum version of `Pillow` for another CVE (matrix-org/synapse#16347) Although, I'm guessing we'd rather leave the minimum version alone and only update `poetry.lock`. I think the problem with updating the minimum is that the packagers for Linux distros will have to deal with not having the latest `pillow` version available and may patch `pillow` a different way.
As per element-hq/synapse#20419 this change broke Element Web clearing user status, which basically means the client is stuck with any status, and users cannot set a new one. EW should move to use DELETE to clear user status, but until then we should ensure the feature is not broken on existing clients in the wild. Should we set a clear deprecation time for rejecting nulls? There might be other clients using profile fields and doing PUT to clear the field. Discussed in [`#element-backend-internal:matrix.org`](https://matrix.to/#/!SGNQGPGUwtcPBUotTL:matrix.org/$b7zid3lLGdFDC8pwy1IvSPv3zl9y1fXEpnnBte9vcQU?via=jki.re&via=element.io&via=matrix.org) [[1]](https://matrix.to/#/!SGNQGPGUwtcPBUotTL:matrix.org/$jTEcHlDBIvKRAKtV-ESXabkPkLia9B7C4JQVkoOxzj0?via=jki.re&via=element.io&via=matrix.org) Reverts a part of element-hq/synapse#20153 by only rejecting null fields when the profile update stream is configured (ie user status requirement). Future work to unrevert tracked by element-hq/synapse#20424
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #303 +/- ##
==========================================
+ Coverage 81.22% 81.29% +0.06%
==========================================
Files 510 511 +1
Lines 74055 74391 +336
Branches 11223 11315 +92
==========================================
+ Hits 60150 60473 +323
+ Misses 10600 10595 -5
- Partials 3305 3323 +18
... and 11 files with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
On our fork, this function doesn't return a value signalling if backfill should occur.
Our fork allows for disabling partial state joins. This variable was renamed during this process. Just bring that forward.
jason-famedly
force-pushed
the
famedly-release/v1.164
branch
from
October 29, 2026 16:54
ecadbc6 to
bab42f5
Compare
itsoyou
approved these changes
Oct 30, 2026
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.
Famedly Synapse v1.164.1_1
Docker images that will be available:
synapse:v1.164.1_1-mod032<- TIM 1.1synapse:v1.164.1_1-mod033<- TIM ProNo significant changes added for Famedly
Matrix Spec support is now at v1.17