Matrix Live

Dept of Status of Matrix 🌡️

Matthew reports

There’s been a lot of discussion in the cryptography community on whether the fact Matrix currently lets homeservers define room membership counts as a E2EE vulnerability or not. On one hand, we consider it to be a low severity issue because we warn users when unexpected devices or users join an E2EE room (if you have verified users; if you haven’t verified all bets are off anyway). On the other hand, many in the cryptography community consider this a serious misdesign. Eitherway, it’s avoidable behaviour and we’re ramping up work now to address it by signing room memberships so the clients control membership rather than the server.

Thib adds

For a balanced coveraged of the vulnerability, see the following articles:

• Matrix.org Foundation — Upgrade now to address E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2
• The original paper — Practically-exploitable Cryptographic Vulnerabilities in Matrix
• ars technica — Serious vulnerabilities in Matrix’s end-to-end encryption have been patched

Dept of Spec 📜

Andrew Morgan (anoa) reports

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://matrix.org/docs/spec/proposals.

MSC Status

New MSCs:

• MSC3901: Deleting state
• [WIP] MSC3898: Native Matrix VoIP signalling for cascaded SFUs
• MSC3896: Appservice media

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC3856: Threads List API
• MSC3771: Read receipts for threads

Spec updates

This last week the SCT has largely been focusing on getting Matrix 1.4 out the door, with threads being the last major piece of it all 🎉

With the inclusion of edits and private read receipts too, it's one of the larger feature releases we've done in a while, but fret not: v1.5 (due approximately November 2022) is expected to be mostly spec maintenance rather than features this time around. That said, if you have any MSCs you think would be good to include in v1.5, please let us know in the #sct-office:matrix.org so we can figure out how to make forward progress on them.

Otherwise, a new simplified spec process guide has been merged to the Matrix Spec Proposals repo. If the MSC process has ever seemed mysterious or complex, or you'd just like a refresher on some spec terminology, feel free to give it a read. Check it out!

Random MSC of the Week

The random MSC of the week is... MSC2596: Proposal to always allow rescinding invites!

When you invite a user to a room in Matrix, you send a membership state event of "invite" with their Matrix ID as a state key. This requires a high enough power level to "invite" users. If you would like to rescind this invite, you would send a second membership state event of "leave". A separate power level is required to the do the latter.

There is an edge case whereas if you have the power level required to invite a user, but not set their membership to "leave" (aka kicking them), then you wind up not being able to rescind an invite. This can be unwelcome, especially if you accidentally invited a user.

This MSC aims to define rescinding an invite as a special case, with separate power level logic from the generic "set a user's membership to 'leave'" action - allowing anyone to rescind an invite they sent regardless of their current power level.

Seems useful to me! If this is something that bothers you, feel free to weigh in on the proposal with feedback.

jaller94 says

Matrix Spec v1.4 for Dash and Zeal

I've updated the Dash/Zeal Docset which you can use to read the Matrix Spec offline.

Link to the new Docset: https://chrpaul.de/dash/Matrix-docset-1.4-1.tgz

If you use Dash or Zeal, give it a try. Let me know, if you find pages that are not working. I hope that Matrix will be included in their list of user-contributed docsets.

Project on Gitlab.com

Note, this is not an official release distribution of the Matrix Spec. Enjoy at your own risk of this breaking or not getting updated.

Dept of Servers 🏢

Sliding Sync Proxy

Kegan says

The sliding sync proxy has seen a number of massive architectural changes to support horizontal scaling in a kubernetes-like environment. The intention is to run a version of this scalable proxy to support expected user loads on matrix.org.

This is currently a work in progress, but the majority of the work is now complete, so watch this space! To get a high-level overview of the changes, take a look at the scaling design doc.

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the matrix.org core team

Shay announces

Hello all. Synapse team has been hard at work, and just released v1.68.0. As mentioned last week, this will be the first version to require Rust. Some other notable features are:

• Add an admin API endpoint to fetch messages within a particular window of time.
• Add an admin API endpoint to find a user based on their external ID in an auth provider. Plus a host of bugfixes, internal changes to speed up Synapse 🚀(including work on faster joins-stay tuned as this is quickly approaching), improvements to the documentation, and more. Check it out here!: https://matrix.org/blog/2022/09/27/synapse-1-68-released

Dendrite (website)

Second generation Matrix homeserver

neilalexander reports

This week we released Dendrite 0.10.0 which contains a number of significant improvements and fixes. If you are running a Dendrite server, please upgrade! Changes include:

• High performance full-text searching has been added to Dendrite
  • Search must be enabled in the search section of the sync_api config before it can be used
  • The search index is stored on the filesystem rather than the sync API database, so a path to a suitable storage location on disk must be configured
• Sync requests should now complete faster and use considerably less database connections as a result of better transactional isolation
• The notifications code has been refactored to hopefully make notifications more reliable
• A new /_dendrite/admin/refreshDevices/{userID} admin endpoint has been added for forcing a refresh of a remote user's device lists without having to modify the database by hand
• A new /_dendrite/admin/fulltext/reindex admin endpoint has been added for rebuilding the search index (although this may take some time)
• A number of bugs in the device list updater have been fixed, which should help considerably with federated device list synchronisation and E2EE reliability
• A state resolution bug has been fixed which should help to prevent unexpected state resets
• The deprecated "origin" field in events will now be correctly ignored in all cases
• Room versions 8 and 9 will now correctly evaluate "knock" join rules and membership states
• A database index has been added to speed up finding room memberships in the sync API (contributed by PiotrKozimor)
• The client API will now return an M_UNRECOGNIZED error for unknown endpoints/methods, which should help with client error handling
• A bug has been fixed when updating push rules which could result in database is locked on SQLite

As always, please feel free to join us in #dendrite:matrix.org for more related discussion.

Dept of Clients 📱

SmallTalk (website)

Minimal Android messenger powered by Matrix

adam reports

A lightweight Android matrix client, focused on family and friends messaging.

It's been a while since the last TWIM update, development is still progressing and the app is still small (1.84mb~ when delivered via app bundle)!

Some of the bigger recent highlights -

• Material You theme
• Notifications overhaul - adding support for UnifiedPush, consistent ping rules and a first pass at invitations.
• Attaching or sharing images.
• A FOSS variant hosted on IzzySoft's F-Droid repository.
• Automatic Monday & Thursday release trains.
• A separate repository for feature requests

There's still a few big features missing like room history, verification and a form of markdown support but if you're feeling brave SmallTalk is in the it's kinda usable phase, links below for trying it out!

| Google Play Beta | F-Droid via IzzySoft | Repository | Matrix room |

Quadrix (website)

A Minimal, simple, multi-platform chat client for the Matrix protocol.

JFA reports

Quadrix v1.3.6 has been released and is available for mobiles and desktops in the respective app stores (the iOS version is still awaiting approval).

The release brings bug fixes, "under the hood" improvements, with upgrades to React 18 and React-Native 0.70, and also two new features:

1. A floating "Send" button just above the virtual keyboard on mobile devices, useful especially on larger phones.
2. An information button on the main screen, for now only used to inform users that a new app version is available.

Please leave feedback/comments at #quadrix:matrix.org or in the issues at https://github.com/alariej/quadrix (stars welcome :-)

Nheko (website)

Desktop client for Matrix using Qt and C++17.

Nico reports

Nheko version 0.10.2 is out now.

This is a security release!

A malicious homeserver could intercept the secrets requests after a verification or when clicking the button for it in the settings and poison the cached secrets in Nheko. This could in theory be used to mark some devices as cross-signed over federation that weren't or to attack the online key backup as such this is fairly high severity.

To protect against this update to 0.10.2 or don't do any verifications of your own devices while on a vulnerable version (and don't hit the request buttons in the settings).

Thanks goes out to the matrix.org team for disclosing this!

Nico announces

As mentionedin the security update earlier, we had a small security release on Wednesday. As part of that we requested our first CVE. While security issues are never something you want to have, this still feels like a major milestone for Nheko. It is certainly not something I even imagined when I started contributing to Nheko and yet here we are. I'd like to thank everyone who made this security release as seamless as it was and I appreciate that all of you were as understanding as you were! I certainly don't take that for granted! But now on to some more fun stuff:

Nheko now has crude support for threading. This means you can start and participate in a thread and replies automatically land in a thread by default. Threads are also now marked in the timeline. Noticeably are ways to filter down the timeline to a specific thread, which will be added at a later date. This now makes Nheko technically implement all new features of Matrix 1.4 in some way or another.

Nheko now also allows you to edit permissions in a community and all the rooms in the community at once as long as you have permission to do so. This should make managing larger communities much easier. As part of that we now also try to handle rate limits more gracefully.

We also upgraded our codebase to some subset of C++20. The major blocker there is Apple, who only implements a very tiny subset of C++20 features at this time (even though they default to C++23...). As part of that we also made our Apple codesigning much more robust and widened our build testing matrix.

Fractal (website)

Matrix messaging app for GNOME written in Rust.

Julian Sparber announces

This week we tagged Fractal as 5.alpha1. This is our first release since Fractal has been rewritten to take advantage of GTK 4 and the Matrix Rust SDK. It is the result of eighteen months of work. Currently supported features are:

• Sending and receiving messages and files
• Sending files via Drag-n-Drop and pasting in the message entry
• Rendering of rich formatted (HTML) messages, as well as media
• Displaying edited messages, redacting messages
• Showing and adding reactions
• Tab completion of user names
• Sending and displaying replies
• Sharing the current location
• Exploring the room directory
• Sorting the rooms by category
• Joining rooms
• Sending and accepting invitations
• Logging into multiple accounts at once
• Logging in with Single-Sign On
• Sending and reading encrypted messages
• Verifying user sessions using cross-signing
• Exporting and importing encryption keys
• Managing the connected devices
• Changing the user profile details
• Deactivating the account

Major missing features are:

• Notifications
• Read markers

As the name implies, this is still considered alpha stage and is not ready for general use just yet. If you want to give this development version a try, you can get it from the [GNOME Apps Nightly flatpak repository] (https://wiki.gnome.org/Apps/Nightly). A list of known issues and missing features for a 5.0 release can be found in the Fractal v5 milestone on Gitlab.

We also published a blogpost about the security quick scan performed by Radically Open Security as part of the NLnet grant https://blogs.gnome.org/jsparber/2022/09/27/fractal-security-audit/

Ement.el (website)

Matrix client for Emacs

alphapapa says

Ement.el, a Matrix client for GNU Emacs, has been updated to version 0.3. It can be installed directly from GNU ELPA with the command M-x package-install RET ement RET.

Since the last announcement on TWIM, the following improvements have been made. The most notable is the addition of the ement-directory commands that allow listing and searching public room directories.

Additions

• Command ement-directory shows a server's room directory.
• Command ement-directory-search searches a server's room directory.
• Command ement-directory-next fetches the next batch of rooms in a directory.
• Command ement-leave-room accepts a FORCE-P argument (interactively, with prefix) to leave a room without prompting.
• Command ement-forget-room accepts a FORCE-P argument (interactively, with prefix) to also leave the room, and to forget it without prompting.
• Option ement-notify-mark-frame-urgent-predicates marks the frame as urgent when (by default) a message mentions the local user or "@room" and the message's room has an open buffer.

Changes

• Read receipts are re-enabled.
• When determining whether a room is considered unread, non-message events like membership changes, reactions, etc. are ignored. This fixes a bug that caused certain rooms that had no message events (like some bridged rooms) to appear as unread when they shouldn't have.
• The ement-taxy-room-list view no longer automatically refreshes the list if the region is active in the buffer. (This allows the user to operate on multiple rooms without the contents of the buffer changing before completing the process.)
• Minor improvements to date/time headers.

Fixes

• Links to only rooms (as opposed to links to events in rooms) may be activated to join them.
• Read receipts mark the last completely visible event (rather than one that's only partially displayed).
• Prevent error when a room avatar image fails to load.
• Info manual export filename.
• Command ement-describe-room for rooms without topics.
• Improve insertion of old messages around existing timestamp headers.
• Reduce D-Bus notification system check timeout to 2 seconds (from the default of 25).
• Compatibility with Emacs 27.

Element Web/Desktop (website)

Secure and independent communication, connected via Matrix. Come talk with us in #element-web:matrix.org!

Danielle reports

• We’ve released a security update this week, more info here. Please make sure to upgrade.
• Now you can create and join new Element Call powered rooms! Element Call rooms are available on develop.element.io so be sure to check it out.
  • Head to; Settings → Labs → Enable Video Rooms Beta, and then enable Element Call video rooms.
• We’re progressing on a new WYSIWYG composer. You’ll be able to avoid markdown (if you want) to craft and preview messages before sending them.
• Updates are being made on the new device manager, including the ability to rename sessions. The whole thing’s is a lot simpler
• There’s also a fix for the missing dot on the notification panel. The bell in the top right should now let you know if you have something new. 🔔

Element iOS (website)

Secure and independent communication for iOS, connected via Matrix. Come talk with us in #element-ios:matrix.org!

Ștefan says

• We’ve released a security update this week, more info here. Please make sure to upgrade.
• There’s been several other bug fixes in iOS this week, including:
  • Fixed the flashing spinner when trying to view media attachments
  • Fixed crash on iPad when you click sign out or invite to element
• We’ve started hearing that performance of the iOS is decreasing - research has started and we’ll be doing what we can!

Element Android (website)

Secure and independent communication for Android, connected via Matrix. Come talk with us in #element-android:matrix.org!

Manu says

• We’ve released a security update this week, more info here. Please make sure to upgrade.
• There’s exciting work happening on deferring DM creation until the first message is sent.
• Also, improvements have been made to the new app layout. It’s available in Labs today but will be the default from the next release so be sure to check it out and let us know what you think?

Element (website)

Everything related to Element but not strictly bound to a client

Danielle announces

There have been security releases across our platforms this week; please make sure to upgrade to the following versions:

• Element Web/Desktop 1.11.8 or later
• Element Android 1.5.1 or later
• Element iOS 1.9.7 or later

The upgrades resolve two critical severity vulnerabilities in end-to-end encryption found in the SDKs which power Element, Beeper, Cinny, SchildiChat, Circuli, Synod.im and any other clients based on matrix-js-sdk, matrix-ios-sdk or matrix-android-sdk2.

The issues are fixed by the upgrades. Neither Element or Matrix have seen any evidence of them being exploited in the wild.

For the full background on the update, visit the Matrix blog post.

Cinny (website)

Cinny is a Matrix client focused on simplicity, elegance and security

Lozenge announces

Cinny v2.2.2 *-----------

In this release we have bumped matrix-js-sdk to v20.0.0 as being a user of SDK, Cinny was affected with vulnerabilities found in it. So please make sure you are using Cinny v2.2.2 or higher.

Apart from that, this release also fixes some issues with markdown, crash on leaving space, and improves View source of events.

Since we are talking about vulnerabilities, since v2 we have also taken zero vulnerable dependency approach and reduced vulnerable npm packages from 18 to just 3. We are working on 3 as well but good thing is that they are just dev dependencies so production builds doesn't include them.

Lastly, if you like you know more about Cinny, join our Matrix space: https://matrix.to/#/#cinny-space:matrix.org or see: https://cinny.in

Dept of Non Chat Clients 🎛️

Thirdroom (website)

A browser-based open metaverse client

Robert Long says

Hey everyone! We just launched Third Room Tech Preview 1! 3D decentralized virtual worlds built on Matrix! Go check it out: https://thirdroom.io

Dept of Widgets 🧩

matrix-widget-api

Dominik Henneke reports

We from Nordeck added support for retrieving related events in Widgets into the matrix-widget-api over the last weeks. With the existing APIs we could not reliable read all the data from the room, as the room timeline is lazily loaded in Element. To learn more about the issue, have a look at the related MSC. With this weeks Element release 1.11.6 this feature has now landed. The change improves using the room as a data storage for Matrix Widgets, which allows us to build cool tools. We keep you updated when we publish our widgets as Open Source.

Dept of SDKs and Frameworks 🧰

matrix-rust-sdk (website)

Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM

ben reports

The Matrix Rust SDK team is proud to announce, that we've released a new version of the SDK to the public: You can get the latest matrix-sdk 0.6.0 (and its subcrates) on crates.io since Wednesday, matrix-sdk-crypto-nodejs 0.1.0-beta.2 via npm since Thursday. Please note that this is a breaking release, with a quite few public API changes, that will probably break your build if you don't change your code for that. You can find broad list and a troubleshooting guide, helping you adapt your code to common errors you'll see in the Upgrade Guide provided. This also marks the first release, we have sliding-sync available behind a feature-flag for testing (note, that it doesn't yet support extensions for to-device messages or E2EE)If you are using latest main, be aware that most deprecated functions are going to be removed soon, as well as the previous experimental-timeline, which will be replaced by the next generation.

As you can imagine the release preparation and last minute fixes to bugs have been the main focus for the team that last two weeks. Most notably, we have fixed a nasty deserialization bug in encrypted to-device messages we found while experimenting with the [upcoming sliding sync extensions] and had to revert the changes to have join and leave return full room-types as that caused internal state inconsistencies, which we have to rework our architecture for to support proper.

️ Wanna hack on matrix rust? Go check out our help wanted tagged issues and join our matrix channel at Matrix Rust SDK.

Dept of Interesting Projects 🛰️

Other Clients October

Asbjørn says

I'd like to propose a community event. It's about exploring Matrix clients.

The concept is simple: For the month of October, only use Matrix clients that you don't normally use.

I have gotten stuck in my ways - using the same Matrix client for years on end. When I was at the Matrix Community Summit in Berlin, I discovered that there are actually many mature clients, with distinct differences and advantages. So, in order to break up my habits a little, I'm going to force myself to not use my daily-driver client for the month of October.

I hope some of you want to join me! To that end, I set up a room for this project, to share our discoveries and frustrations, and compare experiences.

Join the room here: #other-clients-october:olli.ng

Dept of Guides 🧭

Paul reports

I wrote a small blog post about a bot that demonstrates the use of polls as menu-driven bot interaction. DM @menubot:matrix.org to test

Dept of Ping

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

#ping-no-synapse:maunium.net

Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

Hey all,

It’s finally here: threads, edits, and private read receipts. v1.4 has been a little later than usual in the quarter because we wanted to make sure we nailed down all the core MSCs for threads before publishing the spec itself, but we’ve done that now and we’re excited about it.

Matrix 1.3 was just over 3 months ago, though with the relatively large features there and the colossal implementation effort of v1.4 we’re not expecting everyone to have implementations on day 1. Instead, as with all spec releases, we encourage implementations to gradually update over the next few months. We’re additionally planning to make v1.5 (Q4 2022) more of a maintenance update to help make the backlog a bit easier on everyone, though we might prioritize a couple cool features in there too :)

Matrix 1.4 sees 14 MSCs get merged, but we can’t possibly go into detail on them all here. We’ve instead focused on the 3 major features we’re excited about - check out the changelog at the end for the full picture.

🧵 Threads

Threads, a critical feature in terms of parity with other chat systems, have landed thanks to a whopping 6 MSCs: MSC3440, MSC3816, MSC3856, MSC3715, MSC3771, and MSC3773. It’s been a lot of iteration on the reference implementations to get threads this far, and we’re excited to see how the client implementations evolve to provide more structured and less noisy communication for everyone - keep us updated with TWIM posts, please!

Threads have involved changes to event relationships (which were fixed in v1.3), read receipts, and notification counts, resulting in several different models and ways of solving the problem. We think we’ve reached a point that works for conversational threads, though there’s work on the horizon for threads-only rooms, Twitter-style free-form threads, etc to cover more needs of users.

Currently, the demonstration implementation of threads in Synapse and Element is working its way out of the proof-of-concept and beta stages (which were sufficient to validate the MSCs) and are on their way to exiting beta. Keep an eye on the respective blogs for news about production-ready threads!

📝 Edits

Similar to reactions, err, aggregations, MSC2676 and its predecessors have been around for a long while. Edits have existed in the Element clients seemingly forever, and other clients have had troubles trying to implement the same feature: with it now in the spec, it should be a lot easier to bring edits into clients.

For edits, we’ve taken the route of making the MSC match reality, for better or worse. MSCs which improve or add functionality to the system are very much welcome - writing an MSC is relatively easy and helps the whole community.

👥 Private read receipts

Not everyone wants to broadcast that they’ve read a message, but also with read receipts tied into notifications those same people also probably don’t want stuck notifications. To address the problem, we’ve added a new m.read.private receipt type which behaves exactly like m.read, but is only visible to you.

We still have a rework of the notifications system in our long-term plan, but this should hopefully cover the privacy concerns for the time being :)

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

• Remove unused policy room sharing mechanism, as per MSC3844. (#1196)

• Add a .m.rule.room.server_acl push rule to match m.room.server_acl events, as per MSC3786. (#1190, #1201)
• Add Cross-Origin-Resource-Policy (CORP) headers to media repository, as per MSC3828. (#1197)
• Copy a room's type when upgrading it, as per MSC3818. (#1198)
• Add room_types filter and room_type response to /publicRooms, as per MSC3827. (#1199)
• Add m.replace relations (event edits), as per MSC2676. (#1211)
• Add m.read.private receipts, as per MSC2285. (#1216)
• Make m.fully_read optional on /read_markers, as per MSC2285. (#1216)
• Allow m.fully_read markers to be set from /receipts, as per MSC2285. (#1216)
• Add threading via m.thread relations, as per MSC3440, MSC3816, MSC3856, and MSC3715. (#1254)
• Add per-thread notifications and read receipts, as per MSC3771 and MSC3773. (#1255)

• Mention that the /rooms/{roomId}/invite endpoint will return a 200 response if the user is already invited to the room. (#1084)
• Fix various typos throughout the specification. (#1135, #1161, #1164, #1170, #1180, #1215, #1238, #1243)
• Describe return codes for account data endpoints, and clarify that per-room data does not inherit from the global data. (#1155)
• Clarify that policy rule globs work like ACL globs. Contributed by Nico. (#1165)
• Clarify the format of some structures in the End-to-end encryption module. (#1166)
• Add HTML anchors for object definitions in the formatted specification. (#1174)
• Tweak the styling of <code> snippets in tables rendered from OpenAPI definitions. (#1179)
• Update "API Standards" section to clarify how JSON is used. (#1185)
• Clarify that the "device_id", "user_id" and "access_token" fields are required in the response body of POST /_matrix/client/v3/login. (#1210)
• Reinforce the relationship of refreshed access tokens to transaction IDs. (#1236)
• Clarify enum values by separating possible values with commas. (#1240)

Server-Server API

• Add per-thread notifications and read receipts, as per MSC3771 and MSC3773. (#1255)

• Add HTML anchors for object definitions in the formatted specification. (#1174)
• Tweak the styling of <code> snippets in tables rendered from OpenAPI definitions. (#1179)
• Update "API Standards" section to clarify how JSON is used. (#1185)

Application Service API

• Replace homeserver authorization approach with an Authorization header instead of access_token when talking to the application service, as per MSC2832. (#1200)

• Add HTML anchors for object definitions in the formatted specification. (#1174)

Identity Service API

• Add HTML anchors for object definitions in the formatted specification. (#1174)
• Update "API Standards" section to clarify how JSON is used. (#1185)

Push Gateway API

• Add HTML anchors for object definitions in the formatted specification. (#1174)

Room Versions

• For room versions 1 through 10, clarify that events with rejected auth_events must be rejected. (#1137)
• For room versions 2–10: correct a mistaken clarification to the state resolution algorithm. (#1158)
• For room versions 7 through 10: Clarify that invite->knock is actually a legal transition. (#1175)

Appendices

No significant changes.

Internal Changes/Tooling

• Add internal changes changelog section. (#1194)

• Render HTML anchors for object definition tables. (#1191)
• Give rendered-data sections a background and some padding. (#1195)
• Fix rendering of shortcodes within the client-server API. (#1205)
• Fix the spacing of mapping types generated from the OpenAPI spec. (#1230)

TL;DR:

• Two critical severity vulnerabilities in end-to-end encryption were found in the SDKs which power Element, Beeper, Cinny, SchildiChat, Circuli, Synod.im and any other clients based on matrix-js-sdk, matrix-ios-sdk or matrix-android-sdk2.
• These have now been fixed, and we have not seen evidence of them being exploited in the wild. All of the critical vulnerabilities require cooperation from a malicious homeserver to be exploited.
• Please upgrade immediately in order to be protected against these vulnerabilities.
• Clients with other encryption implementations (including Hydrogen, ElementX, Nheko, FluffyChat, Syphon, Timmy, Gomuks and Pantalaimon) are not affected; this is not a protocol bug.
• We take the security of our end-to-end encryption extremely seriously, and we have an ongoing series of public independent audits booked to help guard against future vulnerabilities. We will also be making some protocol changes in the future to provide additional layers of protection.
• This resolves the pre-disclosure issued on September 23rd.

Hi all,

Recently we have been hard at work investigating some subtle security vulnerabilities in certain implementations of Matrix's end-to-end encryption which were responsibly disclosed to us by researchers at Royal Holloway University London, University of Sheffield and Brave Software. Two of these vulnerabilities are critical severity, in that they could allow malicious server admins to attack their users, and are implementation bugs in clients using matrix-js-sdk (e.g. Element Web) or implementations derived from matrix-js-sdk, rather than protocol flaws. matrix-rust-sdk (and other 2nd/3rd generation SDKs) are not affected by these. These vulnerabilities are fixed in today's release, and we are not aware of them having been exploited in the wild.

If you're using Element or an application that shares the same SDKs (Beeper, Cinny, SchildiChat, Circuli, Synod.im) then please upgrade now. Do not perform verification with new devices until you have upgraded.

We'd like to thank the security researchers for investing significant time and effort into doing a deep dive to find these issues, and thus contributing materially to making Matrix more secure for the whole ecosystem. Despite our best efforts, there is always a risk of security issues in software, and we're very glad to have identified and fixed these issues while also taking the opportunity to improve our vulnerability disclosure and coordinated upgrade process.

Please note that the critical severity issues are implementation issues in matrix-js-sdk and derivatives, and are not protocol issues in Matrix. The latest version of the researchers' paper that we've seen incorrectly presents Element as 'the reference Matrix client', and confuses the higher severity implementation bugs with lower severity protocol critique. This is very unfortunate, given Hydrogen, ElementX, Nheko, FluffyChat, Syphon, Timmy, Gomuks and Pantalaimon and other independent implementations are not affected. In fact, every client independently implemented using the Matrix spec seems to have got it right, which speaks well of the protocol. It's only the first generation SDK (predating the spec) and its derivatives which had these bugs.

The two critical severity issues lead to three attack scenarios, all of which are prevented by today's releases:

• "Key/Device Identifier Confusion in SAS Verification" – A bug existed in matrix-js-sdk where it confused together device IDs and cross-signing keys (given under the hood, cross-signing keys are represented as devices). This could be exploited by a malicious server admin to break emoji-based verification when cross-signing is in use, authenticating themselves rather than the target user being verified. This bug is only present in matrix-js-sdk (not iOS or Android SDKs), tracked as a critical severity CVE: CVE-2022-39250.

• "Trusted Impersonation" – matrix-js-sdk (and derived SDKs) suffered from a protocol-confusion bug where it would incorrectly accept to-device messages encrypted by Megolm rather than Olm, attributing them to the Megolm sender rather than the actual sender. As a result, an attacker could fake the trusted sender of to-device messages, allowing them to send fake to-device messages to devices - e.g. fake keys to spoof historical messages from other users. This bug is tracked as a critical severity CVE: CVE-2022-39251 (matrix-js-sdk), CVE-2022-39255 (matrix-ios-sdk) and CVE-2022-39248 (matrix-android-sdk2).

• "Malicious key backup" – the above 'trusted impersonation' bug in matrix-js-sdk (and derived SDKs) could be used by a malicious homeserver admin to add a malicious key backup to the user's account under certain unusual conditions in order to exfiltrate message keys. While we are not aware of this being exploited in the wild, out of an abundance of caution we recommend checking your key backup settings. If you are particularly paranoid you may wish to reset your online key backup. This doesn't have a separate CVE, as the root cause is the same as "Trusted Impersonation".

Three lower priority issues were also identified by the researchers:

• "Semi-trusted Impersonation" – matrix-js-sdk (and derived SDKs) accepted keys forwarded by other users, even if your client didn't request them. As a result, a malicious server admin could fake an encrypted message to look as if it was sent from a given user on that server. However, impersonated messages like this are clearly marked by clients like Element with a clear "The authenticity of this encrypted message can't be guaranteed" warning – which is why we consider this low severity. That said, it's an avoidable attack, and we've fixed this by ensuring that clients don't accept 'unsafe' keys (with the exception of keys forwarded when you invite a user to an existing conversation). In future, in Olm/Megolm v2 we're also linking key-sending events to the underlying recipient Olm identity to ensure that keys cannot be misappropriated. This issue is tracked as a moderate severity CVE: CVE-2022-39249 (matrix-js-sdk), CVE-2022-39257 (matrix-ios-sdk) and CVE-2022-39246 (matrix-android-sdk2).

• "Homeserver Control of Room Membership" – A malicious homeserver can fake invites on behalf of its users to invite malicious users into their conversations, or add malicious devices into its users accounts. However, when this happens, we clearly warn the user: if you have verified the users you are talking to, the room and user will be shown with a big red cross to mark if malicious devices have been added. Similarly, if an unexpected user is invited to a conversation, all users can clearly see and take evasive action. Therefore we consider this a low severity issue. That said, this behaviour can be improved, and we've started work on switching our trust model to trust-on-first-use (so that new untrusted devices are proactively excluded from conversations, even if you haven't explicitly verified their owner) - and we're also looking to add cryptographic signatures to membership events in E2EE rooms to stop impersonated invites. These fixes will land over the coming months.

• "IND-CCA break" – Matrix's usage of AES-CTR to encrypt attachments, secrets and symmetric key backups is not "IND-CCA2 secure", because it does not include the AES initialisation vector within the hash used to secure the payload from tampering. As a result, if an attacker could observe the result of both a given encryption and a given decryption operation, it would be possible to extract the encryption private key. However, this is a purely theoretical attack as Matrix does not provide a way to mount the attack. In the future, we will fix our use of AES-CTR to include the IV within the hash.

We'd like to again thank Martin R. Albrecht and Dan Jones from the Information Security Group at Royal Holloway University London, Benjamin Dowling from Security of Advanced Systems Group, University of Sheffield and Sofía Celi from Brave Software for discovering these issues and responsibly disclosing them to us, and then working with us to agree on an extended disclosure window given the amount of work needed to verify and ship fixes throughout Matrix over the course of the summer period. We welcome any further formal security analysis work, and hope that it will distinguish clearly between Matrix-the-protocol and Matrix implementations like matrix-js-sdk, rather than conflating them. You can read their full paper here.

We'd also like to thank all the downstream Element package maintainers, downstream forks and other affected clients for working together under time constraints for this coordinated release - your patience and understanding is very much appreciated indeed.

Meanwhile, we are taking extreme measures to avoid future E2EE vulnerabilities. You will notice that matrix-rust-sdk, hydrogen-sdk and other 2nd and 3rd generation SDKs were not affected by the bugs at the root cause of the critical issues here. This is precisely why we have been working on replacing the first generation SDKs with a clean, carefully written Rust implementation in the form of matrix-rust-sdk, complete with an ongoing independent public audit.

We started the process of auditing matrix-rust-sdk with the Least Authority vodozemac audit in May, and we have three more audits agreed – covering matrix-rust-sdk-crypto, matrix-rust-sdk, and a whole reference Matrix stack. Ironically, the mitigation work for these vulnerabilities in the legacy SDKs has severely impacted our timelines for finishing matrix-rust-sdk-crypto work (in fact, we had to push back the Least Authority audit of matrix-rust-sdk-crypto given the burndown has not progressed), but we will be shifting to the new audited codebase as rapidly as we possibly can.

Over the coming months we will also introduce our first ever major version update of Olm and Megolm, in order to fix the MAC truncation issue highlighted in the vodozemac audit (Issue J), and reduce the risk of further key-forwarding issues (as per the "Semi-trusted Impersonation" vulnerability above). New conversations will default to using v2 of Olm/Megolm for security, and existing conversations can be optionally upgraded (similar to a 'room version' upgrade in Matrix today). We are also adding extensive end-to-end testing using Polyjuice and Traffic Light to stress-test encryption and improve reliability.

Finally, we will continue our research into layering Matrix over Messaging Layer Security (MLS) - the IETF proposed standard for interoperable end-to-end encrypted group messaging. This work has been delayed by the mitigation activity above, but otherwise it's making good progress and we're excited to see how Decentralised MLS performs in reality against Olm+Megolm v2.

We'd like to apologise to the wider Matrix community for the inconvenience and disruption of these issues, and thank you for your patience while we've resolved them.

Matthew, Denis and the Matrix cryptography & security teams.

Hey everyone, it's time for a new Synapse release! Synapse 1.68 just dropped, let's have a look at what's inside.

Dependency changes

As announced in the Synapse 1.67 release announcement, Synapse 1.68 raises the minimum supported version of SQLite to version v3.27.0. This means that, if your installation of Synapse is using SQLite to manage its database, and the SQLite version used is lower than 3.27, you will need to upgrade to a more recent version before updating to Synapse 1.68. This change does not impact deployments using the matrixdotorg/synapse Docker image.

Synapse 1.68 also introduces the requirement of a Rust compiler for source checkouts. The minimum required version of Rust is 1.58.1. Installations that use pip install matrix-synapse, Debian packages from packages.matrix.org or the matrixdotorg/synapse Docker image to manage and run Synapse, are not impacted by this change.

See the upgrade notes for more information.

Admin API improvements

Synapse 1.68 introduces a new admin API which allows server administrators to query events in a given room that have been sent within a specific time window. This API mirrors the specification's /messages endpoint, and allows, among other things, paginating through a room's history. See the documentation for more information.

This version of Synapse also introduces a new admin API to help administrator of homeservers using an external authentication provider. This endpoint allows looking up a specific identifier on the authentication provider and resolving it into the identifier of the local user it's associated with, if any. See the documentation for more information.

The user admin API has also been updated to allow administrator of homeservers requiring agreement to the server's terms and conditions to view and edit the timestamp at which each user has provided their agreement.

Everything else

Synapse 1.68 greatly improves the validation of user input on most of the account management API endpoints.

This version of Synapse also adds a new request_id_header option to the configuration of HTTP listeners, which allows tracking the identifier Synapse generates for each request in that request's response. This can be helpful for correlating Synapse logs with reverse proxy logs. See the documentation 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) Denis Kariakin, Dirk Klimpel and Beeper, as well as anyone helping us make Synapse better by sharing their feedback and reporting issues.

We're excited to announce the first tech preview of Third Room, an open, standards-based, decentralised vision of the metaverse for the open Web, built entirely on Matrix… without cryptocurrencies, NFTs or walled gardens.

To see what it's all about, head over to https://thirdroom.io/preview - or come chat in #thirdroom-dev:matrix.org to learn more!

We will be releasing a security update to matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2 and clients which implement end-to-end encryption with these libraries, to patch critical security issues, on Wed, Sept 28th. The releases will be published in the afternoon, followed by the disclosure blog post around 16:00 UTC. The affected clients include Element Web, Desktop, iOS and Android. We will also be working with downstream packagers and forks over the coming days to ensure a synchronised release to address affected clients.

Clients using matrix-rust-sdk, hydrogen-sdk and matrix-nio are not affected by these critical issues. We are also auditing third-party client SDKs and clients in advance of the release, and will work with the projects if action is needed. So far we've confirmed that other popular SDK/clients including mtxclient (nheko), Matrix Dart SDK (FluffyChat), Trixnity (Timmy), Syphon, mautrix-go (Gomuks) and mautrix-python are not affected by the issues in question.

If you maintain or package a (potentially) affected E2EE-capable Matrix client and need to coordinate on the release, please contact [email protected].

We advise to upgrade as soon as possible after the patched versions are released.

Thank you for your patience while we work to resolve this issue.