Releases

Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to patch a couple of High severity vulnerabilities (reserved as CVE-2022-36059 for the matrix-js-sdk and CVE-2022-36060 for the matrix-react-sdk).

Affected clients include those which depend on the affected libraries, such as Element Web/Desktop and Cinny. Releases of the affected clients will follow shortly. We advise users of those clients to upgrade at their earliest convenience.

The vulnerabilities give an adversary who you share a room with the ability to carry out a denial-of-service attack against the affected clients, making it not show all of a user's rooms or spaces and/or causing minor temporary corruption.

The full vulnerability details will be disclosed at a later date, to give people time to upgrade and us to perform a more thorough audit of the codebase.

Note that while the vulnerability was to our knowledge never exploited maliciously, some unintentional public testing has left some people affected by the bug. We made a best effort to sanitize this to stop the breakage. If you are affected, you may still need to clear the cache and reload your Matrix client for it to take effect.

We thank Val Lorentz who discovered and reported the vulnerability over the weekend.

Hey everyone! We've just released Synapse 1.65! Let's have a peek at what's inside.

Private read receipts

A feature that the more privacy-focused users of Matrix have been missing was the ability to hide read receipts from other users. Read receipts in rooms can tell a user which messages another user has read in a room. However, they can also be an unwelcome indicator that a user is currently reading a certain room, thus giving away the user's activity on Matrix at a given time.

Hiding one's read receipts from other Matrix users is unfortunately not as straightforward as simply preventing a client from sharing read receipts with the server. This is because read receipts are also used by Matrix homeservers to calculate how much of a room a user has read, and generate notification counts for rooms accordingly.

Synapse 1.65 introduces stable support for private read receipts. This feature, described by MSC2285, allows clients to send a different type of read receipt to the server. This then tells the homeserver to use this piece of information to update the user's notification counts, but not to share it with other users.

Improved room management APIs for modules

This version of Synapse includes two new module API methods to help Synapse modules interact and manage rooms. The first one, lookup_room_alias, allows modules to retrieve the room ID corresponding to a given room alias. This works both for local and remote aliases. The second one, create_room, allows modules to create new rooms on behalf of an existing user.

The update_room_membership method has also been updated in this release of Synapse to allow modules to join a room the server is not already in via federation. This can be done by using the new remote_room_hosts argument, which takes a list of homeservers to try to join via.

Everything else

Synapse 1.65 stabilises the implementation of MSC3827, which allows filtering public room searches on room types. This means it is now possible to search specifically for public spaces. For more information on this feature, see the Synapse 1.63 announcement.

Additionally, Synapse 1.65 implements the new experimental error codes documented by MSC3848. Once stabilised, these error codes will allow clients to show more specific errors to their users about why an event could not be sent.

See the full changelog for a complete list of changes in this release.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, andrewdoh, Julian-Samuel Gebühr and Dirk Klimpel, as well as anyone helping us make Synapse better by sharing their feedback and reporting issues.

It's that time again: there's a new Synapse release, fresh out of the oven! Let's take a look at what's inside Synapse 1.64.

Delegating email verification is now deprecated

Synapse 1.4.0 introduced a configuration option (account_threepid_delegates.email) to allow homeservers to delegate validating the ownership of email addresses to an external identity server. This validation is used by Synapse when adding an email address to a Matrix account, or before performing a password reset.

As of Synapse 1.64, this option is deprecated, and Synapse will print a warning if it is used. This is because this option relies on old API endpoints that have since been removed from the Matrix specification.

Synapse can do this validation internally provided it is configured with details of an SMTP server. Administrators currently relying on account_threepid_delegates.email should therefore ensure that an SMTP server is correctly configured, and remove the account_threepid_delegates.email option. See the configuration guide for more information.

We plan to fully remove this configuration option in Synapse 1.66, which is expected to be released on August 30th.

Note that the equivalent option to validate the ownership of phone numbers (account_threepid_delegates.msisdn) can still be used, though we expect to deprecate it in a future release of Synapse.

Improved TLS support for sending emails

When configuring an SMTP server to use to send out emails to users, server administrators can configure Synapse to use TLS to communicate to that server. Until now, only STARTTLS was supported in this case.

Synapse 1.64 introduces a new force_tls configuration option in the email section of the configuration file. If this new setting is set to true Synapse will use TLS for the initial connection rather than upgrading via STARTTLS.

See the configuration guide for more information.

Memory leak in frozendict

A couple of weeks ago, we identified a memory leak within frozendict, which is a library that Synapse relies on. This would in turn cause Synapse instances to slowly leak memory when processing /sync requests.

We highly encourage server administrators who installed Synapse via pip to upgrade their local version of frozendict to version 2.3.3 or later, which includes a fix to this issue. The Docker image matrixdotorg/synapse and the Debian packages from packages.matrix.org already include the updated library.

Everything else

This version of Synapse introduces support for room version 10! This new room version enables support for the new knock_restricted join rule, to allow knocking into rooms which are otherwise restricted to members of a specific room (or space). See the Matrix specification about room version 10 for more information.

Additionally, Synapse 1.64 features a new rate limiter to limit the rate of joins to the same room. It is intended as a mitigation against abuse scenarios involving joining a lot of users from different homeservers to a room to then send spam across it. See the configuration guide for more information.

This release of Synapse also extends the List Rooms and Room Details admin APIs to include the type of a room in responses, allowing server administrators to differentiate spaces from other rooms.

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, andrewdoh, Thomas Weston, jejo86, villepeh, Jörg Behrmann and Jacek Kuśnierz, as well as anyone helping us make Synapse better by sharing their feedback and reporting issues.

Hey all, it's time for another Synapse release! That's right, Synapse 1.63 is out, let's have a look at it.

Clarifications on "anonymised" server statistics

Synapse has the ability to report usage statistics to the Matrix.org Foundation (or to another location, if configured to do so). These statistics, such as number of users, number of rooms joined by the server, etc. (they don't feature any identifiable information about users and rooms) help us monitor the health of the public federation.

In this release of Synapse, we have updated our public documentation about this feature to clarify how it works and what exactly is being reported. This documentation can be found right here.

Note that previous documentation and prompts surrounding this feature called it "anonymised" server statistics. This could easily be misinterpreted, as while per-user statistics are not reported, homeserver server names are. We have therefore changed said documentation and prompts to be clearer about what is actually reported.

Note that your homeserver will never report any statistics if the report_stats configuration option is set to false. Server admins who are curious about which software is used by the Matrix.org Foundation to record server statistics can check out panopticon.

Improved filtering for public room search

This version of Synapse ships with an experimental implementation of MSC3827 which allows filtering public room search results by room type. This feature will enable better discoverability for Matrix Spaces (which are rooms with a specific type, under the hood), as it will enable clients to search specifically for public spaces.

This feature is still experimental as its MSC hasn't completed the MSC process yet, though it is in its final comment period at the time this post is being written. This means a stable implementation will be coming to Synapse very soon, so watch this space!

Everything else

Synapse 1.63 also includes a new rate limiter to limit invites per issuer. This rate limiter can be configured using the new rc_invites.per_issuer configuration setting, see the documentation for more information.

See the full changelog for a complete list of changes in this release.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, villepeh and Petr Vaněk, as well as anyone helping us make Synapse better by sharing their feedback and reporting issues.

Hey all, Synapse 1.62 is out! Let's have a look inside.

Spam checker improvements

In the past few weeks, the Synapse team has been working with the Matrix.org Trust & Safety team to help module developers build more efficient protections against spam. As a consequence of this work, Synapse 1.62 introduces new ways for modules to communicate the result of actions taken against a specific message or operation through the spam checker module callbacks.

Previously, most spam checker callbacks would be expected to return a boolean indicating whether a specific operation should be qualified as spam. Starting from Synapse 1.62, modules are now expected to return either synapse.module_api.NOT_SPAM (to indicate an action is not spammy), or an error code that is part of synapse.module_api.errors.Codes.

Note that the previous behaviour is still supported but is now deprecated, and will be removed in a future version of Synapse.

See the upgrade notes for a list of the affected callbacks and an example of this change. Note that on top of the list described there, the check_event_for_spam callback was also updated with a similar change in Synapse 1.61.

Everything else

This release of Synapse includes important performance improvements around syncing, specifically around handling device lists and notifications.

Synapse 1.62 also introduce a changes of its optional dependency on the LDAP3 authentication provider module to v0.2.1 in order to fix an issue with usernames that include uppercase characters.

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Sami Olmari, Daniel Aloni, Thumbscrew and Hannes Lerchl.

Hey everyone!

Today we're exceptionally releasing Synapse 1.61.1, which comes as a security release. Server administrators are encouraged to update as soon as possible.

This release fixes a vulnerability with Synapse's URL preview feature. URL previews of some web pages can lead to unbounded recursion, causing the request to either fail, or in some cases crash the running Synapse process.

Homeservers with the url_preview_enabled configuration option set to false (the default value) are unaffected. Instances with the enable_media_repo configuration option set to false are also unaffected, as this also disables the URL preview functionality.

Server administrators who are unable to update Synapse should disable URL previews by setting url_preview_enabled: false in their configuration file. They can also delegate URL preview to a separate, dedicated worker to ensure the process crashing does not impact other functionality of Synapse.

Please see this security advisory for more information.

Hey everyone! Guess what? Synapse 1.61 is out! Let's have a look at it.

Farewell, groups

If you are new to Matrix, you might have not heard of the feature referred to as "groups" or "communities" (depending on the context). This feature allowed grouping rooms and users to better represent a community, one of which being +matrix:matrix.org which used to represent the Matrix community. This may sound similar to Matrix Spaces, and it would make sense since Spaces are meant to be a more powerful replacement for groups.

In Synapse 1.56, support for groups was deprecated, with a plan to fully remove it in a later release of Synapse. This has now been done as of Synapse 1.61, and most of the code supporting this feature has now been removed.

Note that this means that administrators of homeservers using workers can remove endpoints related to groups from their reverse proxy configuration. See the upgrade notes for more information.

Media retention

A common issue we see homeserver administrators struggle with is managing the disk space used by Synapse. A non-negligible part of that disk space usage is dedicated to storing files uploaded by Matrix users, both local and remote.

Up until now Synapse would only provide administrators with limited, manual ways to manage the media store of their homeserver, via the admin API.

As of this release, Synapse now allows administrators to define retention lifetimes for local and remote media. This allows media that hasn't been accessed in a long time to be automatically deleted, therefore freeing up disk space. Server administrators wishing to control media retention more finely can also define different policies for remote and local media.

This feature can be enabled by configuring the media_retention setting, see the configuration guide for more information.

Everything else

This release of Synapse introduces a change in the return value of the check_event_for_spam spam checker module callback, in order to allow modules more flexibility in communicating to users why their messages are rejected. This is part of ongoing improvement works around spam checker callbacks, watch this space next time for more information!

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Dirk Klimpel and Jacek Kuśnierz.

Hey all,

It’s another quarter and therefore another spec release! Matrix 1.2 was released back in February, and while a bit late in the quarter this time around we’ve still got some exciting additions coming to you in this release.

Like last time, the speed of these releases might feel a bit quick for developers: fret not if you’re still working on v1.1 or v1.2 implementations. We’re not expecting that implementations update as soon as a new spec release is published, but rather that the ecosystem gradually update over the course of the next few months. Implementations should be aiming for as close to realtime as they can get though, particularly considering v1.4 is expected to have some large features (more on that later on).

Matrix 1.3 sees 14 MSCs get merged, but we can’t possibly go into detail on them all here. We’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.

Aggregations and the relationships made along the way

It’s no secret that MSC1849-style server-side aggregation of related messages have been in the review backlog for a while. We ended up splitting MSC1849 down into more reviewable chunks like MSC2675, allowing us to finally land the first pieces into Matrix 1.3 today.

In the spec there aren’t currently any defined relationships which make use of aggregations or even the rel_type described by MSC2674, but we do expect that v1.4 of the spec will have support for at least threads (MSC3440) and edits (MSC2676), filling the gap. For now, we’ve decided that holding aggregations back until v1.4 doesn’t make a lot of sense, so we have launched them into the world as-is for custom relations or for clients & servers to prepare for what’s expected to be coming in v1.4 of the spec.

To further prepare for threads, we’ve also removed some restrictions of rich replies through MSC3676, thus allowing replies to be constructed with non-text messages like images. Check out the new rich replies module for more information.

Join if you can, or just knock

When we launched restricted rooms in Matrix 1.2 we noted that we forgot to handle a case where someone might want to support both knocking and restricted rooms at the same time. We’ve fixed that with a stop-gap join rule from MSC3787 in room version 10.

The new knock_restricted join rule allows the room to keep its desire to be restricted whilst also allowing members who do not meet the criteria to knock on the room instead. We’ll likely expand on this sort of mixing of join rules in proposals like MSC3386 down the line, however for now this should cover the gap in support. Next up: figuring out how to make encrypted room history available to these new joiners in a safe way.

A thread for next time

Originally planned for this release, MSC3440-style threads are anticipated to be ready for v1.4 (next quarter) with support for notifications and, of course, a whole new way to communicate in a room.

Threads are one of the more complicated features we’ve tried to land in recent history as it has a large impact on a wide variety of the spec: everything from event relationships (fixed in this release) to read receipts to push notifications needs to be worked out to build a system that not only users can understand, but also the developers trying to build it. With this massive surface area we just weren’t comfortable with adding threads to v1.3 as-is, given problems like notifications aren’t yet fully solved.

Alongside threads, we also anticipate that MSC2676-style message editing will be landing in v1.4, finally specifying how to update an event’s contents without having to redact & re-send. Although message editing has been supported for a long time in some clients, we're excited that it will finally become part of the official specification, meaning it can be implemented more widely. Messaging clients are encouraged to give the proposal an early read and possibly even attempt implementation if not already done to help us ensure the system is in a reasonable state for inclusion in the spec, though we do note that feature requests for edits will likely be deferred to a future MSC.

Keep an eye on This Week In Matrix for updates on what v1.4 is expected to include, and how things are progressing.

The full changelog

MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. The blog post can’t cover them all, but that doesn’t make them any less important! Check out the full changelog below, and the Spec Change Proposals page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode where Matthew covers the proposal process).

Client-Server API

Deprecations

• Deprecate the sender_key and device_id on m.megolm.v1.aes-sha2 events, and the sender_key on m.room_key_request to-device messages, as per MSC3700. (#1101)

Backwards Compatible Changes

• Make from optional on GET /_matrix/client/v3/messages to allow requesting events from the start or end of the room history, as per MSC3567. (#1002)
• Add refresh tokens, per MSC2918. (#1056, #1113)
• Relax the restrictions on Rich Replies, as per MSC3676. (#1062)
• Describe a structured system for event relationships, as per MSC2674. (#1062)
• Describe how relationships between events can be "aggregated", as per MSC2675 and MSC3666. (#1062)
• Add support for a new knock_restricted join rule in supported room versions, as per MSC3787. (#1099)

Spec Clarifications

• Clarify that the url field in m.room.avatar events is not required. (#987)
• Clarify that the type in user-interactive authentication can be omitted. (#989)
• Adjust the OpenAPI specification so that the type Flow information is explicitly defined when the client-server API is rendered. (#1003)
• Correct the default value for invite where it is not specified in an m.room.power_levels event. (#1021)
• Update various links which pointed to the old matrix-doc github repository. (#1032)
• Removed m.room.message.feedback per MSC3582. (#1035)
• Fix various typos throughout the specification. (#1051, #1054, #1059, #1081, #1097, #1110, #1115, #1126, #1127, #1128, #1129, #3681, #3708)
• Clarify that state keys starting with @ are in fact reserved. Regressed from #3658. (#1100)
• Remove unenforced size limit on the name field of m.room.name events. (#3669)
• Remove erroneous room_id field from examples of m.read, m.typing in /sync and m.fully_read in room account data. (#3679)
• Clarify the behaviour of event_match in push rule conditions. (#3690)
• Fix incorrectly referenced m.login.appservice login identifier, instead using m.login.application_service. (#3711)
• Fix membership state transitions to denote that invite->knock and external->leave are valid transitions. (#3730)

Server-Server API

Backwards Compatible Changes

• Add a destination property to the Authorization header, as per MSC3383. (#1067)

Spec Clarifications

• Remove largely unused origin field from PDUs. (#998)
• Update various links which pointed to the old matrix-doc github repository. (#1032)
• Clarify the format for the Authorization header. (#1038, #1067)
• Clarify what a "valid event" means when performing checks on a received PDU. (#1045)
• Clarify that valid_until_ts is in milliseconds, like other timestamps used in Matrix. (#1055)
• Clarify that checks on PDUs should refer to the state before an event. (#1070)
• Clarify the historical handling of non-integer power levels. (#1099)
• Fix various typos throughout the specification. (#1110)
• Correct misleading text for /send_join response. (#3703)
• Clarify that the content for X-Matrix signature validation is the parsed JSON body. (#3727)

Application Service API

Backwards Compatible Changes

• Add timestamp massaging as per MSC3316. (#1094)

Identity Service API

No significant changes.

Push Gateway API

No significant changes.

Room Versions

Backwards Compatible Changes

• Add room version 10 as per MSC3604. (#1099)
• Enforce integer power levels in room version 10 as per MSC3667. (#1099)
• Add a knock_restricted join rule supported by room version 10 as per MSC3787. (#1099)
• Update the default room version to 9 as per MSC3589. (#3739)

Spec Clarifications

• Improve readability and understanding of the state resolution algorithms. (#1037, #1042, #1043, #1120)
• Improve readability of the authorization rules. (#1050)
• For room versions 8, 9, and 10: clarify which homeserver is required to sign the join event. (#1093)
• Clarify that room versions 1 through 9 accept stringy power levels, as noted by MSC3667. (#1099)
• For all room versions: Add m.federate to the authorization rules, as originally intended. (#1103)
• For room versions 2 through 10: More explicitly define the mainline of a power event and the mainline ordering of other events. (#1107)
• For room versions 7, 8, 9, and 10: fix join membership authorization rules when join_rule is knock. (#3737)

Appendices

No significant changes.

Synapse 1.59 is out! Let's see what's new in this version.

Generic worker types

When Synapse instances are subject to high load, it can be useful to use workers to balance the load more effectively. Workers are separate processes that can take some of the load off the main Synapse process, and allow the homeserver to scale more effectively.

In the past, Synapse only provided a specific set of types of workers, each capable of handling a specific set of operations. For some time now we have been working on allowing more flexibility around worker configuration, which started all the way back in Synapse 1.12.0 with the introduction of a generic worker application type.

Synapse 1.59 furthers this work by deprecating the synapse.app.appservice and synapse.app.user_dir worker application types. Homeserver administrators should change the configuration of instances using these types to the generic synapse.app.generic_worker application type, and use the notify_appservices_from_worker and update_user_directory_from_worker to delegate application service and user directory work (respectively) to a worker.

See the upgrade notes for more information on this change.

Push rules

Push rules allow Matrix clients to define notification rules on a homeserver. One often reported issue with notification in Matrix is the fact that notifications are sent out when server ACLs, which define which server(s) can and cannot interact in a room, change. This is especially annoying during big waves of abuse, as there might be multiple servers that need to be banned from rooms, thus causing a lot of unneeded notifications.

Synapse 1.59 now supports silencing server ACL updates, by implementing the new push rule documented in MSC3786. However, since this MSC hasn't been incorporated into the spec yet, this behaviour is disabled by default in Synapse: see the implementation pull request for more information on turning it on.

Synapse 1.59 also allows third-party modules to validate and change the actions associated with an existing push rule via the Module API. This is helpful for modules wishing to, for example, configuring specific notification settings when new users register.

Everything else

As of Synapse 1.59, Synapse will not communicate the name of devices over federation (unless configured otherwise), in order to better preserve user privacy. See the upgrade notes for more information.

Also note that we have issued a patch release for 1.59 (1.59.1) which fixes a long-standing bug that started to bite a good amount of server administrators. Server admins that are looking into upgrading their instance to Synapse 1.59 are recommended to upgrade to 1.59.1 rather than 1.59.0.

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Dirk Klimpel, Šimon Brandner, henryclw and Andrew Do.

Synapse 1.58 is out! Let's dive into this new release.

Poetry

If you've been reading the past few Synapse release announcements, you might have already heard about our efforts to integrate Poetry into Synapse. Poetry is a tool which manages dependencies of a Python project. Its killer feature is its lockfile, which explicitly pins all dependencies (direct and transitive) to a fixed version, even across multiple Python versions and platforms. See more about why we choose Poetry here.

During the past few months, we've been hard at work converting Synapse and its CI to use Poetry. The goal is to make our Docker images and Debian packages more reproducible and to provide a fixed, known-good environment for CI. This will help us to ensure the stability and security of Synapse installations.

Synapse 1.57's Docker image was the first to use Poetry; after a successful trial, this was extended to Synapse 1.58's Debian packages. Installations from PyPI using pip will not use the locked environment, though everyone is welcome to install from source using our lockfile.

Huge props to David from the Synapse team for leading the work on this front.

Everything else

This release of Synapse also includes performance improvements around sharing device list updates, which should greatly improve login times for large Matrix accounts.

Synapse 1.58 also features the implementation of two MSCs: MSC3383 to include a destination parameter in federation authentication headers, and MSC2815 which (if enabled) allows room moderators to see the content of a redacted event (as long as it hasn't already been deleted by the homeserver).

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Dirk Klimpel, Famedly and Sami Olmari.