After quite a significant gap between releases ā version 0.3.11 was released at the beginning of March ā weāre happy to finally announce the release of Dendrite 0.4.0 today!
The full changelog for the release is available on GitHub, but we wanted to take the opportunity to talk a little about some of the changes that have gone into this release.
Recently our release cadence for Dendrite has slowed as we have spent more time within the team working on Pinecone and Low Bandwidth Matrix. These are major areas of research for us which we hope will unlock a number of new opportunities within the Matrix ecosystem, allowing us to build on Matrix anywhere and to reduce the protocol-level footprint. However, Dendrite has not been forgotten amidst the excitement and we will be spending more time working on Dendrite again in the coming months.
State storage
One of the major features in v0.4.0 is that weāve introduced newly-refactored state storage in the roomserver database. The goal here is to make state storage significantly more efficient by ensuring that we deduplicate state blocks and snapshots wherever we can. By ensuring that all state blocks and snapshots are ordered strictly, and by enforcing uniqueness constraints on the hashes of the blocks/snapshots, weāve been able to achieve this.
This was largely spurred on by watching dendrite.matrix.org consuming a rather alarming amount of disk space on a daily basis. In this particular instance, moving to the new state storage resulted in a 15x improvement on disk utilisation for state blocks and a further 2x improvement for state snapshot references immediately after the migration, and the growth rate of the database has slowed substantially since.
Ensuring that we donāt waste disk space is one of the most important factors in ensuring that Dendrite operates well at any scale ā future datacentre deployments supporting many users will find storage overheads decreased and small/embedded single-user deployments (such as P2P, on mobile devices or in the browser) will fit much more effectively onto resource-constrained targets.
After upgrading to v0.4.0, Dendrite will run an automatic migration to update your homeserver to the new state storage format. This might take a while on larger databases so please expect some downtime.
Optimisations
Weāve continued to squeeze further optimisations into the federation and state resolution code, aiming to reduce the amount of CPU burn and memory utilisation. Some of the feedback that we receive most often from those that have been experimenting with the Dendrite betas is around the sudden spikes in resource usage, especially when joined to large rooms.
The bulk of this resource usage comes either from attempting to reconcile missing events or running state resolution in rooms with lots of members, as potentially large state sets of events need to be brought into memory in order to do so. Weāve introduced some transaction-level caches for dealing with missing auth/prev events to reduce the memory pressure and weāve also tweaked the caching around around /get_missing_events to ensure we donāt duplicate any state events in memory.
Resource spikes arenāt completely eliminated but this should smooth out CPU and memory utilisation significantly. In the case of dendrite.matrix.org, which is joined to some 6500 rooms at present, memory utilisation of the Dendrite process typically sits around 1.5GB at present.
State Resolution v2 has also seen further optimisations in the power-level checking, which should reduce CPU usage even more.
Bridges
Thanks to Half-Shotās perseverance and contributions, weāve merged a couple PRs and worked on some further fixes for getting Application Services working correctly in Dendrite. Whilst not entirely feature-complete and with a number of features still to go, enough support is now present to support basic bridging functionality.
Weāve done quite a bit of preliminary testing with matrix-appservice-irc and have also heard a number of success stories from the community with mautrix-whatsapp and mautrix-telegram. Others may work too ā let us know what you find!
Bug-hunting
A number of bugs in various places (including the roomserver, federation API and media API) which could cause Dendrite to crash have also been fixed. Some of these have been contributed by the community in pull requests, so we extend our thanks to anyone who has submitted a fix to the project.
A special mention also goes to Jakob Varmose Bentzen for reporting a security issue to us around the legacy /v1/register endpoint, where a flaw in the legacy shared secret registration allowed malicious users to create accounts. Weāve since removed this legacy endpoint and the vulnerability is now fixed.
Whatās next
There are still a number of missing user-facing features which we will be working on over the coming months, as well as some architectural issues that we will look to address.
A notable area of work involves attempting to remove the dependency on Kafka for polylith deployments. Kafka is very resource-heavy in operation and somewhat limits us to the types of interactions that we can perform between components. Itās also very difficult to manage retention correctly, in the interests of not endlessly consuming disk space here either.
As usual, Dendrite is still considered beta so you may not want to rely on it for production systems, although it should be stable enough to experiment with. If you find any bugs or anything that doesnāt look right, please let us know:
Iām the Principal Data Scientist for the Ansible Community. Weāre hoping to switch to Matrix as our primary platform in the near future, and Iāve just written up my thoughts on why thatās a good idea, what the consequences might be, and where we go from here. Find it at https://ansible.github.io/community/posts/matrix_and_ansible.html
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://spec.matrix.org/unstable/proposals.
A concrete plan has been drafted for publishing the new spec release, and is currently undergoing execution. This release will include many changes that have built up since the last release (back before the new spec redesign even), as well as the new Matrix Global Version Number scheme. Look forward to it dropping soon!
Otherwise Bruno has been hard at work continuing to push forward the various aggregation MSCs (1234). MSC3083 (restricted room memberships) is being updated as part of finalising the new Spaces feature as well as MSC2716 (history import).
As well as lots of new MSCs as listed above. Busy times!
The last two weeks I worked on a few very big optimizations. We also almost finished sqlite support for Conduit, which is slower than sled in benchmarks, but has much better RAM usage characteristics.
Batch up and cache /sync responses for when clients time out
LRU cache for deserialized PDUs
More efficient state res by only fetching events it needs
Big(int) news! This week Matrix.org processed its 2^31st event, exceeding the range of a PostgreSQL integer column for the first time. This caused a bit of a scramble in the aftermath of last weekās spam attack, as we had a few integer columns in our schema which we needed to convert to bigint. Fortunately, we were able to complete the change sufficiently in advance (#8255), and also took the opportunity to audit other columns and sequences in the database which could conceivably overflow. Synapse 1.38, due out next week, will automatically migrate homeservers when they upgrade. We run the migration as a background task, so homeservers should continue functioning as normal throughout, though they may use a bit more disk and memory, especially when rebuilding indexes for the new bigint column.
Weāre also starting to hone in on our teamās goals for this quarter, and itās looking like our primary focus will be on improving room join speeds. Wish us luck!
Lastly, weāre overjoyed to announce that @reivilibre, a former intern on the backend team, joined Element this week! We canāt wait to see where he helps us take Synapse!
matrix-puppeteer-line: A bridge for LINE Messenger based on running LINEās Chrome extension in Puppeteer.
This week was spent on adding proper support for LINE user joins/leaves (though invites/kicks are still a TODO), bug fixes, and ease of deployment. Docker and systemd setups will be ready shortly.
And this bridge should soon be listed on https://matrix.org/bridges/, if it isnāt already š Thanks madlittlemods (Eric Eastwood) for accepting the PR!
SchildiChat is a fork of Element that focuses on UI changes such as message bubbles and a unified chat list for both direct messages and groups, which is a more familiar approach to users of other popular instant messengers.
There are two announcements that we can share with you this week:
SchildiChat for Android is back in the Google Play Store! Users who have previously installed the release using our own F-Droid repo will be able to update without the need to re-install. All previous ways to install the app will remain available as well.
You can now help us translate SchildiChat using Weblate! Note that this only contains SchildiChat-specific translations, we continue to use Elementās translations where possible.
Apart from that, we have mainly been focusing on smaller improvements and fixes, while staying up-to-date with new Element releases.
For more information about SchildiChat, feel free to visit our website or check out our source code!
Also, feel free to join our Matrix rooms, which you can find in the new SchildiChat space: #schildichat:matrix.org
Nheko
Nheko is a desktop client using Qt and C++17. It supports E2EE and intends to be full featured and nice to look at
Spaces work is making progress. Some rooms can now be previewed. To improve that situation, I wrote an MSC to preview specific rooms. Alternatively we will try to get the previews for the few rooms you arenāt joined to from the space summary API, currently we are just fetching the existing state. You can also now join previewed rooms and the design of joining invites was adapted to match it.
red_skyāļø went through the pain of fixing the Windows builds after we changed our http backend last week. So if you want to try it out, you can test it on Windows. We also replaced the old, boring spinner with an animated Nheko logo. If you see that a lot and think it is Nhekoās fault, donāt hesitate to open an issue! But in most cases it will probably be your server. Sadly no screenshot of how the spinner looks like, my server is too fast and taking a proper screenshot is too much effort because of that. ;p
We also fixed an issue with updating device lists in the develop version of Nheko. If you were using the nightlies, now is a good time to update! In more E2EE news, symmetric megolm backup fixes the issues I had with the online key backup, so looking forward to implementing that.
The latest release of opsdroid is out with various fixes which can be seen in the changelog. The main point to note for matrix users is that older versions of matrix-nio (the matrix client library used by opsdroid) did not support the synapse change to omit optional fields from sync. Therefore if you are using our docker images you will need to update to 0.23 to get a container with the newest matrix-nio included.
The other change which is relevant to matrix users is that Oleg has added support for version 2 of the Rasa NLU framework, so you can once again do open source, self hosted natural language bots.
For the first graph the credit fully goes to Gwmngilfen :)
The second one is in log scale for both axis but essentially the same :)
This is obviously currently very spare but I hope to add more statistics when I understand R lang :) This is in fact my first time doing something with R so my skillset is limited :)
Run Matrix Python bots inside of Docker Containers with Simple-Matrix-Bot-Lib and Docker!
This is a guide for isolating and running your Matrix bot within a Docker container. It is also applicable to bots written using other libraries and languages.
Hi everyone! Did you ever feel lost in the Matrix world? The room directory is big, but itās still hard to find something you like. Or are you a room moderator, but there is not much activity in your room because it doesnāt have enough users?
This is why I want to share rooms (or spaces) I find interesting.
In meta twim news, the twim updates bot (which posts in #twim_updates:cadair.com) has been upgraded to opsdroid 0.23 and now correctly keeps the formatted body when an event is edited.
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.
This is a long read, but a detailed argument. Also please note that this is was produced for the purpose of an MSc course of study, it was not commissioned for any other purpose, as the preamble makes clear.
Next, a high billing for Beeper this week, who have been working hard and getting product out!
Itās been a month since our last update. A lot of the work since then has been on making everything more reliable, but weāve also added new features to our clients and started making some new bridges.
Desktop
Added thread UI for Slack-bridged rooms. Internally theyāre just replies like before, but the client will intelligently collapse replies in Slack rooms into threads.
Merged upstream Element additions like voice messages.
Also merged some features that arenāt in Element yet, like Giphy integration.
iOS
Released Beeper iOS to Testflight.
Android
Added grouping rooms by chat network based on the m.bridge state event. The UI is similar to spaces, but theyāre not actual Matrix spaces (yet).
Added support for Android 11ās āconversationā notifications.
Bridges
Android Messages is turning out difficult to reverse-engineer to a sufficiently reliable level, so weāre building a new SMS bridge into our Android app. Itāll also be available as a standalone open-source app, which already exists at https://gitlab.com/beeper/android-sms (but doesnāt have any setup instructions yet).
Weāve funded development of a LinkedIn bridge. sumner will post a more detailed update about that.
Bruno has been working on aggregations as part of his work for Hydrogen. He reported:
Iāve been cleaning up the relations MSCs, finding a balance between documenting the current state and not losing track of community concerns. Iāve started with MSC 2674 which is the very basic format of relations, and will move on to annotations/reactions (MSC 2677) next week.
Dept of Servers š¢
Synapse
Synapse is a popular homeserver written in Python.
Weāre pleased to announce the release of Synapse 1.37.1 this week, which includes mitigations for the recent distributed spam attack across the public Matrix network. We advise upgrading as soon as possible.
Got another week of Helm Chart updates, with the Synapse chart getting a bunch of worker improvements and additional configurability, as well as being updated to first 1.37.0 and then 1.37.1
Iām excited to announce that I started working on a new bridge for bringing LinkedIn messages to Matrix! Itās currently in the early stages of development and not production-ready. The current feature set includes: backfill from LinkedIn, user name and profile picture sync, message sending from Matrix -> LinkedIn, and real-time message puppetting from LinkedIn -> Matrix. Thereās much more to come, and you can join #linkedin-matrix:nevarro.space for updates. Development is being funded by Beeper, and is being designed with integration into Beeper as itās primary goal. However, the bridge is open source (Apache 2.0) and will be available to self-host. The source code is here: https://github.com/sumnerevans/linkedin-matrix.
Great work from Sumner! Glad to see people have the option to bridge their LinkedIn messages!
matrix-puppeteer-line: A bridge for LINE Messenger based on running LINEās Chrome extension in Puppeteer.
Better LINE->Matrix read receipt bridging is now supported in the testing branch! The bridge now checks all LINE chats (not just the most recently-used one) to see if messages you sent have been read (in LINE). This works by cycling through all LINE chats where the final message is posted by you and doesnāt have a āReadā marker on it yet (or for multi-user chats, if your last message hasnāt been read by everyone in the room).
With that, Iāll consider the bridge to be in Early Beta! š Iām now testing the bridge for myself to iron out a few kinks, and am preparing a PR to the matrix.org webpage to have this listed on https://matrix.org/bridges/.
This addon for the WebThings gateway lets you send Matrix messages when your IoT fridge is empty ā or whatever you have connected to your gateway.
The update fixes predefined messages getting sent to the default room and is the first to be tested against gateway version 1.0.0.
https://gitlab.com/webthings/matrix-adapter or in the addon list of your WebThings gateway
This week, NeoChat gained support for a Global Menu on Plasma and macOS. Aside from that, we fixed a few crashes.
But the biggest news of the week is that we will get funding from NLNet to implement E2EE support in Quotient and NeoChat as part of their grants to improve the internet. We will report on our progress on that front here!
This is terrific news, big thanks to NLNet for making this choice!
FluffyChat
FluffyChat is the cutest cross-platform matrix client. It is available for Android, iOS, Web and Desktop.
We merged the Spaces branch, which means Nheko master can now show some spaces. Peeking unjoined rooms, nesting spaces and creating them should be coming soon. We are also looking into how to fit knocking into the UI (we already rendered incoming knocks in the timeline for a while).
You can also now edit still pending messages, which should help if your server is slow and you notice a typo. The edit will then get queued and be sent as soon as the server acknowledges they received the original message. Apart from that there have been some improvements to the readability of the room list and some other UI elements.
Last but not least, we switched out our entire http backend from Boost to Curl. For that I wrote a simple wrapper around Curl. This fixes about 10 issues around connection shutdown, brings proxy support, http/2 and http/3 support and in general makes Nheko crash less and reduces latency a LOT! This will obviously cause some pain for packagers, but I hope it isnāt too bad. Some of the issues this fixes only had 2 digits in our bugtracker and one was even filed by benpa!
Chris tweaked the UI in various places. Itās a lot of small details that together make for a smoother experience. I encourage you to read the details in the description of !782. This is the only MR that landed since last week, but our people have been hard at work nonetheless. Kai blogged about his journey working on the search bar of doom and Alejandro shared his own struggle. In the meantime, Julianās work has mostly happened upstream in matrix-rust-sdk.
Element Clients
Updates sent by the teams
Delight team
Spaces:
Research: Weāve been reaching out to people to walk us through how they use Spaces now and what theyād like to see different to help us learn and iterate;
Restricted room access: Some good progress towards shipping improved team spaces
Some major progress on conversion to TypeScript, finding some bugs along the way. The main source of the element-desktop project is now fully converted to TypeScript!
A styled player component for the audio messages feature, available in the labs section.
v0.5.19 of the matrix-bot-sdk is out now with fixed power level checking (with an added utility function), improved default error logging, and a typo fix in reply creation. Check it out, and visit #matrix-bot-sdk:t2bot.io for help & support.
Exciting new update, we can now wireguard an on-premises server from just about anywhere and make it work with the AWX system. This is useful when your server doesnāt have a static or public IP address, or when some other networking issue prevents you from running a Matrix service on it.
Mjolnir is a moderation bot for communities on Matrix. It helps with a lot of the actions covered by the moderation guide, including capabilities to apply bans from other trusted communities. Itās still a bit terse in its documentation, but if youāre looking for a featureful moderation bot then itās worth a go.
In related news, Mjolnir v0.1.18 is out with a couple quality of life fixes - if youāve been bothered by the log spam, itās now fixed :)
I started a tiny repo to collect various limits and related factoids about the Matrix specification and implementations. I hope that distilling and summarising such things at glance will make it easier to see what is and is not possible.
If you know of more that should be listed, please contribute! š
Self hosting your own Matrix server on a Raspberry Pi
@ed:selfhostingblog.com of theselfhostingblog.com has written a guide on getting started with Synapse on a Raspberry Pi using Docker Compose. You can read it here.
Together with J. Ryan Stinnett, I created the š #matrix-science-reading-group:dsn.tm.kit.edu for exchange of and on scientific papers, books and related resources on all things Matrix: Topics ranging from peer-to-peer broadcast overlay networks over conflict-free replicated data types to end-to-end encryption. Investigating security, performance, deployability, or whatever else is interesting, by methods from observation over simulation to formal verification. šļø Please join if you want to read about papers that might not be Matrix-related enough to make it into TWIM, or want to engage in the discussion. š The resulting papers are collected at: https://github.com/jryans/awesome-matrix#research
Hi everyone! Did you ever feel lost in the Matrix world? The room directory is big, but itās still hard to find something you like. Or are you a room moderator, but there is not much activity in your room because it doesnāt have enough users?
This is why I want to share rooms (or spaces) I find interesting.
āA public space for Free/Open Source Software maintainers to swap notes and discuss their craft. Inspired by https://github.com/github/maintainerweek, all maintainers welcome!ā
Over the last few days weāve seen a distributed spam attack across the public Matrix network, where large numbers of spambots have been registered across servers with open registration and then used to flood abusive traffic into rooms such as Matrix HQ.
The spam itself has been handled by temporarily banning the abused servers. However, on Monday and Tuesday the volume of traffic triggered performance problems for the homeservers participating in targeted rooms (e.g. memory explosions, or very delayed federation). This was due to a combination of factors, but one of the most important ones was Synapse issue #9490: that one busy room could cause head-of-line blocking, starving your server from processing events in other rooms, causing all traffic to fall behind.
Weāre happy to say that Synapse 1.37.1 fixes this and we now process inbound federation traffic asynchronously, ensuring that one busy room wonāt impact others. First impressions are that this has significantly improved federation performance and end-to-end encryption stability ā for instance, new E2EE keys from remote users for a given conversation should arrive immediately rather than being blocked behind other traffic.
Please upgrade to Synapse 1.37.1 as soon as possible, in order to increase resilience to any other traffic spikes.
Also, we highly recommend that you disable open registration or, if you keep it enabled, use SSO or require email validation to avoid abusive signups. Empirically adding a CAPTCHA is not enough. Otherwise you may find your server blocked all over the place if it is hosting spambots.
Finally, if your server has open registration, PLEASE check whether spambots have been registered on your server, and deactivate them. Once deactivated, you will need to contact abuse@matrix.org to request that blocks on your server are removed.
Your best bet for spotting and neutralising dormant spambots is to review signups on your homeserver over the past 3-5 days and deactivate suspicious users. We do not recommend relying solely on lists of suspicious IP addresses for this task, as the distributed nature of the attack means any such list is likely to be incomplete or include shared proxies which may also catch legitimate users.
To ease review, weāre working on an auditing script in #10290; feedback on whether this is useful would be appreciated. Problematic accounts can then be dealt with using the Deactivate Account Admin API.
Meanwhile, over to Dan for the Synapse 1.37 release notes.
Synapse 1.37 Release Announcement
Synapse 1.37 is now available!
**Note: ** The legacy APIs for Spam Checker extension modules are now considered deprecated and targeted for removal in August. Please see the module docs for information on updating.
This release also removes Synapseās built-in support for the obsolete ACMEv1 protocol for automatically obtaining TLS certificates. Server administrators should place Synapse behind a reverse proxy for TLS termination, or switch to a standalone ACMEv2 client like certbot.
Knock, knock?
After nearly 18 months and 129 commits, Synapse now includes support for MSC2403: Add āknockā feature and Room Version 7! This feature allows users to directly request admittance to private rooms, without having to track down an invitation out-of-band. One caveat: Though the server-side foundation is there, knocking is not yet implemented in clients.
A Unified Interface for Extension Modules
Third party modules can customize Synapseās behavior, implementing things like bespoke media storage providers or user event filters. However, Synapse previously lacked a unified means of enumerating and configuring third-party modules. That changes with Synapse 1.37, which introduces a new, generic interface for extensions.
This new interface consolidates configuration into one place, allowing for more flexibility and granularity by explicitly registering callbacks with specific hooks. You can learn more about the new module API in the docs linked above, or in Matrix Live S6E29, due out this Friday, July 2nd.
Safer Reauthentication
User-interactive authentication (āUIAā) is required for potentially dangerous actions like removing devices or uploading cross-signing keys. However, Synapse can optionally be configured to provide a brief grace period such that users are not prompted to re-authenticate on actions taken shortly after logging in or otherwise authenticating.
This improves user experience, but also creates risks for clients which rely on UIA as a guard against actions like account deactivation. Synapse 1.37 protects users by exempting especially risky actions from the grace period. See #10184 for details.
Smaller Improvements
Weāve landed a number of smaller improvements which, together, make Synapse more responsive and reliable. We now:
More efficiently respond to key requests, preventing excessive load (#10221, #10144)
Render docs for each vX.Y Synapse release, starting with v1.37 (#10198)
Ensure that log entries from failures during early startup are not lost (#10191)
Have a notion of database schema ācompatibility versionsā, allowing for more graceful upgrades and downgrades of Synapse (docs)
Weāve also resolved two bugs which could cause sync requests to immediately return with empty payloads (#8518), producing a tight loop of repeated network requests.
Hi everyone! Did you ever feel lost in the Matrix world? The room directory is big, but itās still hard to find something you like. Or are you a room moderator, but there is not much activity in your room because it doesnāt have enough users?
This is why I want to share rooms (or spaces) I find interesting.
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.
Spaces work continues with MSC3083 (Restricted room memberships), which will include a new room version due to the new join_rule of `restricted. On the other side of things, MSC3245 (voice messages) and by extension extensible events, is moving as the implementation work is pushed forward. Lots of activity on MSC3215 (improved moderation tooling) as well which will no doubt prove to be invaluable as the Matrix network continues to grow.
Among those exciting updates, we also have the usual churn of bug fixes and improvements across the board. Many updates to the documentation as well as we lean into using the new Synapse documentation site more and more. Please help us test the RC if you can!
This week too sees some Kubernetes chart updates, with element-web being updated to 1.7.31 and matrix-synapse getting some fixes for envvars and mounts, as well as some improvements to the ingress support.
It has been several months since we last updated you on MSC2716 for backfilling historical messages into existing rooms but we made some big progress this week and merged an experimental Synapse implementation taking us one step closer to importing the massive archive of messages on Gitter over to Matrix! This iteration will only make the historical messages visible on the local homeserver but we have plans to make them federate in the next. Itās still early days on this before we can actually use it on Gitter. Here is a proof of concept to get your juices flowing:
In terms of code, this week we didnāt get much activity. The only noteworthy news is that we can now send spoilers, and use two new commands: /tableflip and /unflip thanks to Smitty van Bodegom.
Aside from that, we had 2 productive BoFs during Akademy 2021. The first one was about creating a library with shared chat visual components for KDEās chat apps: NeoChat for Matrix, Tok for Telegram and Kaidan for XMPP, KDE Connect and Spacebar for SMS, ā¦ The second BoF was more about NeoChat and Quotient and we discussed how to move forwards with some problems (e.g. non-hacky text input auto-completion) but also the roadmap around E2EE, Spaces and Widgets support. Speaking about E2EE, we will have some very good news to announce next week, stay tuned!
/me only learned about /tableflip and /unflip this todayā¦ and looking forward to this E2EE news!
In the past couple of weeks, Alejandro and Kai started the coding period of their GSoC internship and explained on their blogs what they will be working on. Their projects are respectively to add support for multiple accounts, and to bring Fractal Next to feature parity with current stable. Read more details on their blogs, and subscribe to them to keep informed as they go!
Julian managed to land the āExploreā view, our room directory. There may be some changes down the road, but it looks good for now:
Newcomer Giuseppe De Palma removed bashisms from our git hook because they were preventing him from contributing. They then went on to tweak the history style to remove the grey background around it. They also got rid of a papercut from the login form: before his intervention, users needed to provide the full homeserver URL with the http:// or https:// scheme prefix. It will now default to HTTPS.
We also did some housekeeping work that should improve the experience for people joining us on the Fractal Next fun. After being away for a while, Christopher Davis came back with a patch to add a couple more build related directories to our .gitignore. Julian cleaned up the pseudo-milestone description that we had in the README, now that we have a proper Gitlab milestone. And finally, I added a warning on the login screen to better reflect on the Work In Progress state of the branch.
Element Clients
Updates from the teams! Android will return next week.
Delight team
Spaces:
Drag and drop for reordering Spaces is now live on Android! And testable on develop for Web
Weāve also added labs flags to Web & Android to test a few different things, in particular
Toggling āHomeā to show all rooms, or only rooms which donāt belong to Spaces
Toggling to not show People in Spaces
Please try them out! After living with a different config for a few days, weād love to hear your feedback!
Web
1.7.31 released on Monday
Nightly builds of Element Desktop optimised for Apple silicon are now available for testing! Please give it a try and report any issues.
Added libera.chat to room directory on develop, staging, and app. It will appear in desktop builds as well next time they update.
On develop
Various CI tweaks and performance improvements
In flight
Adding large account performance tests
iOS
1.4.2 released on Monday. 1.4.3 with the fix on wellknown on Thursday
0.0.95 RC is out, available from the usual place at GitHub, and also as Flatpak from Flathub. The usual stabilisaton/bug fixing work, no new features compared to betas. This version is considerably better, and more stable, than 0.0.9.4 - packagers are welcome to push it as if it were the final release. Translators, please help to complete more languages: Polish is at 90%, Spanish almost 80%, and French just below 60% - you can make a difference!
Dept of Encryption š
New paper: āKey Agreement for Decentralized Secure Group Messaging with Strong Security Guaranteesā
Here is a scientific paper for all interested in decentralized end-to-end encryption cryptography protocols, like Matrixā Megolm, or the MLS future of Matrix: The preprint āKey Agreement for Decentralized Secure Group Messaging with Strong Security Guaranteesā by Weidner, Kleppmann et al., which will appear in the ACM CCS 2021 Conference, surveys existing centralized and decentralized end-to-end cryptography protocols, Olm/Megolm (labeled as āMatrixā) among them, and discusses why the Messaging Layer Security (MLS) IETF draft has its problems with decentralization. Following that, they come up with their own decentralized protocol, including a security and performance analysis. They improve asymptotic complexity when compared to Olm/Megolm, and the assumptions on the underlying communication layer are easily fulfilled by Matrix. They also discuss that the very good asympotic complexity of MLS cannot be reached for a decentralized end-to-end cryptography protocol.
Last weekās news actually, but libQuotient master branch can built with Qt 6 now, laying ground for the GSoC works on PyQuotient - Python bindings for libQuotient. The library has also been updated to follow the latest CS API specification, which means basic low-level support for knocking, with higher-level library API for it coming later.
Polyjuice Util is a library of Matrix functions for Elixir that can be used for both client-side and server-side applications. Polyjuice Util 0.2.0 has been released, which includes functions for common errors, handling identifiers, and for checking room permissions. Thanks to Nico for his contributions to this release. This release also contains some backward-incompatible changes. See the changelog for more information.
Polyjuice Client 0.4.1 has also been released, which uses the new Polyjuice Util release, and adds support for the whoami endpoint (thanks to multiprise).
Hello dear Synapse Admins, synadm v0.30 is out. lt seems I was in āstory telling modeā already when I wrote the release notes yesterday. That should perfectly suit a TWIM article as well š So there you go, copy/pasted from https://github.com/JOJ0/synadm/releases/tag/v0.30 with love:
Note that this is meant to be a convenience function in case a Synapse homeserver admin wants to quickly help users e.g set specific settings available via regular Matrix calls and not the Synapse admin API directly. Also note that it is not meant to replace the awesome Matrix CLI tools that are already out there. matrix-commander, matrixcli to mention just a few.
It implements a plain login on a Matrix server using username and password. It can even be used to retrieve a token for an admin user, e.g helpful for setting up fresh synadm installations. Read about it here
Thanks to the friendly people in #synadm:peek-a-boo.at for reviewing, testing, discussing functionality and giving advice. And for this release, a special thanks to @hpd:hpdeifel.de https://github.com/hpdeifel
with the change of policy we deployed on GNOMEās Matrix instance, it occurred to me that we had overlooked an important aspect in our relationship with Matrix: do we own our Matrix account? And the answer isā¦ maybe! In this post I cover the differences between personal account, organisation-owned account, the importance of segregating activities on Matrixā¦ and why this may change with Portable Identities in the future
the French government deployed Tchap, an instant messaging based on Matrix. They are looking for tech and processes oriented people to improve the service.
I know this isnāt TWIM-worthy, but I figured people in this room would find it interesting: yesterday there was a very popular post on reddit about how we donāt appreciate email enough, and in the comments there were some mentions of matrix as the counterpart for messaging:
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.
Finally MSC3173: Expose stripped state events to potential joiners reached FCP this week, which is a step towards informing clients about the state of a room before they attempt to join or knock on it, which allows for nicer client UX when deciding whether you want to join a room or not.
This weekās big news is the release of Synapse 1.36 which completely eliminates memory spikes when joining rooms! Iāll let the āJoining Matrix HQā graph speak for itself:
We also fixed a few bugs with presence (especially over federation or on a worker process), and would strongly encourage you to upgrade.
Weāll spend the next few weeks on smaller changes as we prepare our Q3 goals, but we look forward to sharing those with you when we have them.
Happy weekend, TWiM!
Happy weekend to you too! Letās upgrade to 1.36 this weekend!
Actively deployed to pixie.townās Synapse now, and running very smoothly. Happy graphs show 91% of requests are handled without Synapse involved.
Also demonstrated the very seamless drop-in enable and disable, just changing the reverse proxy url back and forth from Synapse, and with this you could cautiously try this out for your own server, but stay in touch with #synapse-media-proxy:pixie.town
Heisenbridge is a bouncer-style Matrix IRC bridge.
Plumbing private/invite-only rooms is possible
IRC quit messages are visible as leave reasons
Nick changes are now displayed in leave reason instead of a notice
Prioritized Matrix->IRC queue for improved responsiveness while sending out a lot of messages
Improved AUTOCMD with multi-command support
Improved ZNC support with display of external messages by yourself
Improved plumbing message formatting: ZWSP in sender names, smarter truncation
IRC user displayname cases update if PRIVMSG source differs from current
New rooms respect cases of IRC nicks and channels
Conduit related fixes, thanks Peetz0r!
Channels with keys on IRCnet now rejoin correctly
Finally 100% working identd so it works on all tested networks
Cleaned up SASL support which makes server messages during authentication visible
Proper cleanup when leaving Heisenbridge rooms
Tiny bugfixes everywhere!
Currently working towards 1.0 release so mostly bug hunting and improving existing code and features.
Call for mutual help! The plumb feature needs more testing on busy IRC channels. If you need to plumb public Matrix rooms and IRC channels on any IRC network that does not have a public bridge available or just want to use a relaybot on IRC side for some reason hit me up on #heisenbridge:vi.fi and we can setup a test plumb, free of charge! Only requirements are that I can lurk around to monitor how it works and thereās nothing offensive on-topic.
In other news @warthog9 submitted an article to opensource.com how to use ZNC and Heisenbridge together to keep using your existing IRC bouncer with Heisenbridge as a client for it. Pretty cool stuff!
Thanks!
matrix-appservice-irc weights in at release 0.27.0
Hola everyone! Today weāre releasing the latest in bridge greatness, matrix-appservice-irc 0.27.0. This release contains the bulk of our work done for libera.chat. As always, thanks to the community for testing, writing up issues and creating PRs so that we can build better bridges to our friends on other networks.
The highlights are:
Username/password SASL authentication support. The bridge now lets you set a !username.
Bridge operators can now choose to block messages in the I->M direction while Matrix users are not joined to IRC as a privacy preservation technique.
You can now configure the bridge to publish rooms to the public room directory (rather than the appservice directory). The bridge can now also use the whole alias namespace (e.g. #foo:libera.chat -> #foo).
Numerous bug fixes and quality of life fixes!
This is now live on libera.chat, and will be live on the other bridges very soon!
matrix-puppeteer-line: A bridge for LINE Messenger based on running LINEās Chrome extension in Puppeteer.
Even more read receipt improvements are here! In summary, with the magic of MSC2409, the bridge shouldnāt ever āviewā a LINE chat on your behalf in order to sync a message (which would send a read receipt to your chat contacts, even though you didnāt read the chat yourself). For LINE messages that require viewing its chat in order to be bridged, like images/stickers (to get the image) and messages in multi-user chats (to know who sent them), the bridge instead sends a āplaceholderā message that gets updated with the real LINE message content when you view the placeholder. That way, the bridge will only view a LINE chat when you view its Matrix portal.
A few stability fixes have been pushed as well. Namely, sync should be less likely to accidentally skip chats.
Only one final read receipt improvement remains, for LINE->Matrix read receipt bridging (which I mentioned last week): to make the bridge check all LINE chats (not just the most recently-used one) to see if messages you sent have been read (in LINE). This will work by cycling through all LINE chats where the final message is posted by you and doesnāt have a āReadā marker on it yet.
Once that is taken care of, Iāll consider the bridge to be in beta! š
Starting work on message bubbles, building on existing work from the community
Fuzzy matching for the room list filter in progress
Coming soon
Voice messages: weāre in the testing stages and looking for feedback before they go live. Give it a go and let us know!
iOS
The new side menu and the new UI to join a room by alias are on develop.
The security settings screen has been updated to match the UX of element-web. The iOS app now uses the same wording for āSecurity Phraseā and āSecurity Keyā
Device dehydration now works in the SDK. We need to polish the work before merging the PR
Voice message is still progressing well. We need to figure out how we will deal with the ogg format on iOS. We also need to add a cache to improve performance in the audio (and encryption) processing
Android
Theme changes are now merged on develop and will be included in release 1.1.10. All the themes and styles have been moved to a dedicated gradle module. This is the first step to be able to develop new app features using dedicated modules. Other steps are required for us to be able to do that though (create a core module, etc.).
All the PlayStore descriptions have been pushed to the PlayStore using Fastlane, should be live soon. F-Droid already has the up to date translations for the store assets. Thanks to all the contributors on Weblate!
Release 1.1.10 will be prepared today. Expect it to be in production next week if everything is fine.
Last week was another busy week in NeoChat. Carl made the room list sidebar resizable and improved the responsive design of the settings pages.
Janet Blackquill implemented custom emojis using the im.ponies.user_emotes extension. For now auto-completion works, the custom emojis will be displayed in the emoji picker and lastly there is also an UI to add new emojis. We plan to implement more of the im.ponies MSC (custom stickers, sticker pack) soon :)
Smitty van Bodegom implemented spoilers and added /j and /leave alias for /join and /part. He also fixed the spellchecker trying to spellcheck commands like /rainbowme.
Oh and finally NeoChat was also featured on last weekās āThis Week in Linuxā podcast: https://www.youtube.com/watch?v=XaPWx_z_50s Donāt forget to follow us on Twitter @NeoChatKDE or Mastodon neochat@fosstodon.org, to get your latest news about NeoChat.
Akademy is also happening this weekend and next week. KDE is using Matrix and BigBlueButton for the conference. There will be a lot of talk, training and bofs. We have a bof the 22th June at 16th. Itās virtual and everyone is welcome to join and discuss with us NeoChat development.
FluffyChat
FluffyChat is the cutest cross-platform matrix client. It is available for Android, iOS, Web and Desktop.
FluffyChat 0.32.0 is out now šŖ and targets improved stability and a new onboarding flow where single sign on is now the more prominent way to get new users into the app.
This release also introduces a complete rewritten database under the hood based on the key value store Hive instead of sqlite.
This should improve the overall stability and the performance of the web version.
Hereās the FluffyChat subreddit, in order to provide more structured way of discussions, keep questions asked again and again in one place, and refer to older answers whenever the need is, as well as just to hang out https://www.reddit.com/r/fluffychat/
Nheko
Nheko is a desktop client using Qt, Boost.Asio and C++17. It supports E2EE and intends to be full featured and nice to look at
Weāve slowly been adding spaces support. Nheko can now show your spaces in the sidebar, filter on them and show a (very basic) overview page for a space. We are still playing around with what to actually put there, allow you to expand and collapse subspaces in the sidebar and allowing you to peek into rooms in a space, which you havenāt joined yet. Creating and modifying spaces is also still work in progress until we figure out a proper design for it.
It provides a fully featured base for Dart and Flutter applications including E2EE, and Cross Signing. After more than 2 years of development we now declared it as stable. The Matrix Dart SDK (formerly known as famedly SDK) was initially a rewrite of the FluffyChat backend which was written in JavaScript. It came a long way since then and is now the base for the Famedly App and for the Flutter version of FluffyChat.
Hyper-targeted callback: Hey Naren, Famedly are the Matrix-using folk I was telling you about. This is the latest version of their Dart work and will be a great place to start building from.
Hi, I started a small, static webapp last weekend for viewing and modifying room states.
It can locally store multiple access tokens and helps debug and maintain room permissions.
Itās not looking fancy yet but already proved useful for many of the matrix.org IRC support requests.
The GitLab maubot plugin recently received major improvements to webhook handling. The Matrix messages now look much nicer (similar to the GitHub maubot plugin) and it also sends fancy reactions for CI status.
Itās already in use in #nheko:nheko.im and Beeperās internal commit log room. Itās unfortunately not yet available on t2bot.io, because Iām too lazy to write a migration script to copy data from the very old standalone gitlab bot written in Go.
In the future I might figure out some interoperability between the github and gitlab plugins so that I can also get CI reactions for my repos (which are primarily on github, but have CI on gitlab)
Dept of Events and Talks š£ļø
Interoperability event hosted by, and featuring, Matrix
Tomorrow Element will host an event alongside Protonmail, Open-Xchange and Open Forum Europe on the DMA and the topic of interoperability. This will be hosted on Matrix, based on the infrastructure first used during FOSDEM. The event will be livestreamed over on #interop-sme:matrix.org
Iāve been invited to appear in the latest episode of Clever Cloudās tech podcast Message Ć CaractĆØre Informatique, where we talked mostly about Matrix and decentralisation, but also about a bunch of other interesting things ranging from timbl minting his source code as an NFT to how to hack autonomous car with sound. It was loads of fun, thanks to them for the invite!
After some fixes the bot is now back in shape. This means that all Rooms should again have the correct names from now on and accept invites again. Be aware the bot currently doesnt support encrypted rooms.
Also if you use the apis please note that the content is gzip encoded. The server currently doesnt respect the Accept-Encoding Header.
On the side of internal changes is now that the retries are limited to 5 times instead the previously buggy amount. This should reduce join requests from my server drastically.
After having tried to convince several people to join the Matrix, my main conclusion is that itās too difficult for people. Apps that big tech companies produce are so simple that having to choose a client, choose (or set up) a homeserver and building bridges is too much of a push factor from the Matrix.
To help those people, Iāve written a quick guide that should help people without a programming background join the Matrix. Iām using this as a reference when people ask how they could join the Matrix, feel free to do this yourself as well: https://noordstar.me/b/how-to-join-matrix.md
Hi everyone! Did you ever feel lost in the Matrix world? The room directory is big, but itās still hard to find something you like. Or are you a room moderator, but there is not much activity in your room because it doesnāt have enough users?
This is why I want to share rooms (or spaces) I find interesting.
āPeople reading eBooks usually know Calibre (https://calibre-ebook.com/), one of the most prominent ebook management solutions by Kovid Goyal. Weāve had an āunofficialā (as in: Kovid doesnāt like real-time communications :) ) channel on what used to be freenode that Iāve moved to Libera and which is - of course! - bridged to #calibreā ~Philantrop
We did it! Synapse no longer experiences a memory spike when joining large / complex rooms.
These improvements mainly arise from processing join responses incrementally, rather than trying to load everything into memory at once. However, realizing these gains involved a fair bit of rewriting, as the entire processing pipeline had to work incrementally, and with appropriately sized batches, to avoid downstream bottlenecks. You can hear more about our original plans for this work in last monthās Matrix Live: S6E23 ā Dan and Erik talk about Synapse.
Presence Improvements
Running presence on a single worker process is now expected to work correctly. This feature first debuted in Synapse 1.33, but a few bugs cropped up which could lead to presence state becoming outdated. With #10149 merged, we believe the last of these issues to be resolved.
We had also noticed a recent increase in presence load on federation workers; this was ultimately tracked to two bugs, both fixed in this release: We were processing local presence via federation workers (#10163) and we were occasionally sending duplicate presence updates (#10165).
With both issues fixed, outgoing federation load has returned to normal levels:
(Thank you to David Mehren for this graph from issue #10153)
Everything Else
Synapse now has two new Admin APIs for unprotecting and removing media from quarantine, thanks to contributions by dklimpel.
Synapse now implements the stable /_matrix/client/r0/rooms/{roomId}/aliases endpoint originally introduced by MSC2432, and, thanks to contributions by govynnus, makes the reason and score fields of event reports optional per MSC2414.
These are just the highlights; please see the Release Notes for a complete list of changes in this release.
Hi all! My name is Denis and Iām a security
researcher. Six months ago, I started working for
Element on doing dedicated security research on important Matrix projects.
After some initial focus on Synapse, I decided to take a closer look at
libolm. In this entry, Iād like to
present an overview of that work, along with some early fruits that came out of
it.
TL;DR: we found some bugs which had crept in since libolmās original audit in
2016, thanks to properly overhauling our fuzzing capability, and weād like to
tell you all about it! The bugs were not easily exploitable (if at all), and
have already been fixed.
To give a bit of a background, libolm is a cryptographic library implementing
the Double Ratchet
Algorithm pioneered by
Signal and it is the cryptographic workhorse behind Matrix. The classic
algorithm is called Olm in Matrix land, but libolm also implements Megolm which
is a variant for efficient encrypted group chats between many participants.
Since libolm is currently used in all Matrix clients supporting end-to-end
encryption, it makes for a particularly juicy target. The present state of
libolmās monopoly on Matrix encryption is somewhat unfortunate ā luckily there
are some exciting new developments on the horizon, such as the
vodozemac
implementation in Rust. But for now, weāre stuck with libolm.
To start, I decided to do a bit of fuzzing. libolm already had a fuzzing setup
using AFL, but it was written a while ago. The state of the art in fuzzing had
advanced quite rapidly in the last few years, so the setup was missing many
modern features and techniques. As an example, the fuzzing setup was configured
to use the now ancient afl-gcc coverage mode, which can be slower than the more
modern LLVM-based coverage by a factor of 2.
I also noticed that the fuzzing was done with non-hardened binaries (instead of
using something like ASAN), so many memory errors couldāve gone unnoticed.
There were also no corpora available from previous fuzzing runs and some of the
newer code was not covered by the harnesses.
Preparation
I decided to tackle these one by one, adding ASAN and MSAN builds as a first
step. I took the opportunity to switch to AFL++ since
it is a drop-in replacement and contains numerous improvements, notably
improved coverage modes which are either much faster (e.g. LLVM-PCGUARD) or
guaranteed to have no collisions (LTO)1. AFL++ also optimizes mutation
scheduling (by using scheduling algorithms from
AFLFast) and mutation operator selection
(through MOpt). All of this makes
it much more efficient at discovering bugs.
After this, I changed the existing harnesses to use AFLās persistent mode
(which lowers process creation overhead and thus increases fuzzing
performance). This change, combined with the switch to a newer coverage mode,
increased the fuzzing exec/s from ~2.5k to ~5.5k on my machine, so this is not
an insignificant gain!
After this preparatory work, I generated a small initial corpus and ran a small
fleet of fuzzers with varying parameters. Almost immediately, I started getting
heaps of crashes. Luckily, after some investigation, these turned out not to be
serious bugs in the library but a double-free in the fuzzing harness! The
double-free only got triggered when the input was of size 0. It also only
happened with AFL++ and not vanilla AFL, presumably due to differences in input
trimming logic, which must be the reason no one noticed this earlier. I quickly
came up with a patch and resumed.
The plot thickens
I let the fuzzers run for a while. Since ASAN introduces a bit of a performance
overhead, I only run a single AFL instance with ASAN variant of the binary.
This is okay because all fuzzer instances actually synchronize their findings,
which means every instance gets to see every input which increases coverage.
When I came back to check, there was another crash waiting. This time the
crashing input wasnāt being generated continually so it looked much more
promising ā and only the ASAN instance was crashing. A-ha!
Running the offending input on the ASAN variant of the harness revealed it was
an invalid read one byte past the end of a heap buffer. The read was happening
in the base64 decoder:
Following the stack trace, I quickly pinpointed the root of the bug: the logic
of the decoder was subtly flawed, unconditionally accessing a remainder
byte2 in the base64 input which might not actually be there.
This occurs when the input is 1 (mod 4) in length, which can never happen in
a valid base64 payload, but of course we cannot assume all inputs are
necessarily valid payloads. Specifically, if the payload was not 0 (mod 4) in
length, the code was assuming it was at least 2 (mod 4) or more in length and
immediately read the second byte. This spurious byte was then incorporated into
the output value.
I examined the code in an attempt to find a way to have it leak more than
a single byte, but it was impossible. As it turned out, not even the full byte
of useful information was encoded into the output ā due to the way the byte is
encoded, only about 6 bits of useful information ended up in the output value.
Still, even a single leaked bit is too much in a cryptographic context. Could
we do some heap hacking so that something of interest is placed there and then
have it be leaked to us?
I next tracked down all call sites of the vulnerable function
olm::decode_base64. Most of them were immune to the problem since they were
preceded with calls to another function, olm::decode_base64_length, which
checks that the base64 payload is of legal length. This left me with only a few
potentially vulnerable call sites, so I examined where their base64 inputs come
from. Promisingly, two of them received input from other conversation
participants, but they either had no way of leaking the information back to the
attacker or they hardcoded the number of bytes to be processed, after ensuring
the input was of some minimum length. The output of the remaining function
olm_pk_decrypt is never sent anywhere externally, so there
was again no way of leaking the data to the attacker.
In conclusion, even though this invalid read is a valid bug, I was not able to
find a working exploit for it.
But wait a second! Something was still bothering me about olm_pk_decrypt.
Itās a fairly complex function, receives several string inputs from the
homeserver and it itself isnāt tested by any of the harnesses. Furthermore,
the reason I started looking at it in the first place is that it was missing
the olm::decode_base64_length check. Perhaps it warrants a closer look?
It does
And sure enough, there was something amiss. As olm_pk_decrypt receives three
base64 inputs from the homeserver: the ciphertext to decrypt, an ephemeral
public key and a MAC. All three are eventually passed to olm::decode_base64
to be decoded. Yet there was only a single length check there, to ensure the
decrypted ciphertext would fit its output buffer. What would happen if the
server returned a public key that was longer than expected?
As can be seen from the snippet, the decoded version of public key gets written
to ephemeral.public_key, which is an array allocated on the stack. If the
input is longer than expected, this will become a stack buffer overflow.
The purpose of olm_pk_decrypt is to decrypt secrets previously stored by
a Matrix device on the homeserver. The point of encryption is to prevent the
server from learning these secrets since theyāre supposed to be known only by
your own devices. One use case for this mechanism is to allow one of your
devices to store encrypted end-to-end encryption keys on the homeserver. Your
other devices can then retrieve those keys from the homeserver, making it
possible to view all of your private conversations on each of your devices.
I decided to go for an end-to-end test to confirm the bug is triggerable by
connecting with the latest Element Android from my test phone to my homeserver,
with mitmproxy sitting in between. This allowed me to
write a small mitmproxy script which intercepts HTTP calls fetching the E2E
encryption keys from the homeserver and modifies the response so that the key
is longer than expected.
import json
from mitmproxy import ctx, http
defresponse(flow: http.HTTPFlow) -> None:
if ("/_matrix/client/unstable/room_keys/keys"in flow.request.pretty_url
This longer value is then eventually passed by Element Android to libolmās
olm_pk_decrypt, which triggers the buffer overflow. With all of that in
place, I deleted the local encryption key backup on my device and asked for it
to be restored from the server:
F libc : stack corruption detected (-fstack-protector)
F libc : Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 24517 (DefaultDispatch), pid 24459 (im.vector.app)
F DEBUG : x28 00000000000001d0 x29 0000007945dd37d0
F DEBUG : sp 0000007945dd3790 lr 00000079e732e00c pc 00000079e732e034
Impact
This vulnerability is a server-controlled stack buffer overflow in Matrix
clients supporting room key backup.
Of course, the largest fear stemming from any remotely controlled stack buffer
overflow is code execution. This is perhaps even doubly so in a cryptographic
library, where we have the additional worry of an attacker being able to leak
our dearly protected conversations.
The federated architecture of Matrix may be somewhat of a mitigating
circumstance in this case, since users are much more likely to know and trust
the homeserver owner, but we donāt want to have to rely on this trust.
Native binaries
Luckily, on its own, this bug is not enough to successfully execute code on
native binaries. By default, libolm is compiled for all supported targets with
stack canaries (also called stack protectors or stack cookies), which are magic
values unknown to the attacker, placed just before the current functionās frame
on the stack. This value is checked upon returning from the function ā if its
value is changed, the process aborts itself to prevent further damage. This is
evident from the Abort message: 'stack corruption detected (-fstack-protector)' message above. Besides canaries, other system-level
protections exist to make exploiting bugs such as this harder, such as ASLR.
Therefore, to achieve remote code execution, an attacker would need to find
additional vulnerabilities which would allow him to exfiltrate the stack canary
and addresses of key memory locations from the system.
WASM
With WASM, the analysis is much more complicated due to its very different
memory and execution model. In WASM, the unmanaged stack is generally much more
vulnerable due to it missing support for stack canaries. This implies a stack
buffer overflow can not only overwrite the frame of the function in which the
overflow occurred but also all parent frames.
On the other hand, due to typed calls and much stronger control-flow integrity
techniques, itās much harder for the attacker to make the code do something
that is (maliciously) useful. Notably, return addresses live outside unmanaged
memory and are out of reach to the attacker. Because of this, the primary way
of influencing code execution is by manipulating call_indirect instructions
in such a way as to call.
Once the problems were identified, the patches were rather
trivial and the issues were promptly resolved. The first libolm
release that includes the fix is 3.2.3 which was released on 2021-05-25.
We reached out to all Matrix clients which were determined to be affected. The
Element client versions which first fix the issue are as follows:
Element Web/Desktop: v1.7.29
Element Android: v1.1.9
Element iOS: v1.4.0
For the mobile clients, these versions are already available in their
respective application stores at the time of publishing this post. If you
havenāt already, please upgrade.
Future work
Even though the fuzzing setup is in a much better shape now (or rather will be,
since I still have some PRs to merge upstream), thereās still a lot that can be
done to further improve it.
Right now, there are undoubtedly parts of the codebase that are not fuzzed
well. The reasons for this range from the obvious, like some parts of the code
simply not being called by any the existing harnesses, to more subtle ones such
as the fact that cryptographic operations form a nearly-insurmountable natural
barrier for naive fuzzing operations3. Finally, some of
the existing harnesses accept additional parameters as command-line arguments,
meaning we would have to re-run the same harness with different values of those
parameters in order to reach full coverage of the code. This is suboptimal.
So the plan for future work is roughly as follows:
Write missing harnesses to cover more portions of the codebase.
Write starting corpus generators. These should generate believable, valid
input for each of the harnesses. For example, for the decryption harness, we
should generate a variety of encrypted messages: empty, short, long, text,
binary, etc.
Modify the harnesses so that their extra parameters are determined from the
fuzzed input. This will allow the fuzzer to vary these itself, which reduces
the importance of the human in the loop and makes it harder to forget some
combination.
Fuzz for some time until coverage stops increasing. The corpora generated
should be saved so that future fuzzing attempts can resume from an earlier
point so that this work is not wasted.
Use afl-cov to investigate which parts of the code are not covered well or
at all. This should inform us what further changes are needed.
Write intelligent, custom mutators. These will allow the fuzzer to take
a valid input and easily produce another valid input instead of only
corrupting it with a high probability.
Design harnesses which test for wanted semantic properties instead of only
memory errors.
Itās very exciting that weāre able to do full-time security research on Matrix
these days (thanks to Elementās funding), and going forwards weāll publish any
interesting discoveries for the visibility and education of the whole Matrix
community. Weād also like to remind everyone that we run an official Security
Disclosure Policy for
Matrix.org and weād welcome other researchers to come join our Hall of Fame!
(And hopefully we will get more bounty programmes running in future.)
Hi everyone! Did you ever feel lost in the Matrix world? The room directory is big, but itās still hard to find something you like. Or are you a room
moderator, but there is not much activity in your room because it doesnāt have enough users?
This is why I want to share rooms (or spaces) I find interesting.
MSC3079: Low Bandwidth CS API now has an experimental implementation containing a proxy server and mobile bindings! In addition, thereās a blog post explaining how to use this implementation to add low bandwidth support to your servers/clients! This implementation will use about 22% of the bandwidth that the normal CS API would use. Please be aware that low bandwidth Matrix is in its infancy and is subject to change without notice.
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.
I have spent quite a bit of time lately working on Pinecone network convergence for P2P Matrix. Thereās still quite a bit to do in order to call Pinecone ācompleteā, but a network of 50 nodes now bootstraps entirely from cold much more quickly and converges on full end-to-end reachability in roughly 6 seconds. This is a significant improvement to before! Keep an eye out for future P2P Matrix demo builds using these new protocol changes.
This chart also represents interest in Pinecone over time!
Hello! The last two weeks I mostly tried to make our database backend swappable so we donāt need to rely on the sled database anymore. I was able to try out
rocksdb, but there were bugs in the rust bindings which required inefficient and unsafe workarounds.
If you know about other key-value databases that work better with Rust, please comment on the issue:
This week I implemented the remaining API route for URL previewing. Already has some nicer url preview results like showing images with Twitter posts and proper YouTube previews instead of the cookie wall text :)
With this, synapse-media-proxy should be a drop-in overlay for all Synapseās /_matrix/media routes.
I donāt really recommend using it in prod yet however, but I have a test instance that could use some responsible disclosure pentesting at https://media.pixie.town, please DM me @f0x:pixie.town if you find anything :)
After over a year of work and over a hundred commits, weāre now one major step closer to supporting MSC 2403: Add āKnockā feature, which allows users to request admission to rooms which would otherwise be invite-only. Specifically, last Wednesday we merged (#6739) which is an experimental implementation of the MSC, under an unstable prefix. Knocking is not available in any current room versions ā we need to implement room version 7 for that ā but the remaining work is minimalĀ¹ compared to what it took to get to this point. š Major kudos to Sorunome, Anoa, and Clokep for their work on both the spec and implementation.
Otherwise weāre looking forward to releasing Synapse 1.36 early next week, and we have some great things in storeā¦ but Iāll not spoil them today! š¤«
From everyone on the Synapse team, have a great weekend!
Ā¹: Well, on the server-side at least. No clients support knocking, yetā¦
Hi folks. Some time ago I asked here about any projects that provided a local Matrix ānodeā through docker, and it seemed not much existed in that space, so I went ahead and created the following repo:
Docker-based development environment for Matrix. Provides a local sandbox with the following pre-configured services:
synapse: the reference homeserver implementation
synapse-admin: homeserver admin UI
element: a web-based Matrix client
If this is something that would be useful to you, feel free to give it a try and send some feedback, either here or through GitHub issues. Thanks in advance! I hope this is helpful to some of you š
Thanks uhoreg for passing this on! Looks like a really useful way to get a local env running
Hi folks, just a quick update on the Libera.chat bridge situation. Weāre still rapidly working on the bridge, the milestone highlights for this week are:
Nearly 6k Matrix users are now connected to IRC and growing by the minute.
Weāre midway though our #matrix* Freenode to Libera channel/bridge migrations.
FOSDEM has been migrated over
Weāre still working through our backlog of migration requests from users, a lot of you phoned in!
Weāre still continuing to rapidly work on the bridge, with a release expected on Monday š¤. For any of you who arenāt in the know yet, you can start bridging to libera.chat by simply joining a channel like #libera-matrix:libera.chat or by searching the libera.chat room directory.
Iām hoping weāll be nearing the end of our journey on this bridge, and it will settle into a natural stable state over the coming days! Anyway, thanks everyone for your patience and we hope to see you on Matrix or IRC!
Hi bridge followers, today weāve released 0.27.0-rc1 of the IRC bridge containing a huge number of changes following all the work weāve been doing on libera.chat. Notable things to call out in this release are:
Weāve refactored the node-irc library to be typescripty and modern, rather than the quite old JS that it was.
SASL support for username/password auth has landed, which hopefully means a smoother login process for many. (Weāre aware of some issues around setting usernames, watch this space)
Allowing you to spin up the bridge with complete control over the alias namespace of a host (e.g. #libera:libera.chat links to #libera).
And finally, a privacy feature to block incoming IRC messages when Matrix users are not all joined which is requested by some IRC networks.
matrix-puppeteer-line: A bridge for LINE Messenger based on running LINEās Chrome extension in Puppeteer.
Read receipt improvements are here! They are in temporary branches until theyāve been tested for stability:
The better-receipts-dm branch contains some smarts to prevent Puppeteer from having to āviewā a LINE DM chat in order to sync it, which would make the contact youāre DMing think youāve read their messages when it was really Puppeteer that āsawā them. However, this doesnāt work for non-text messages (like images) or messages in group chats.
The better-receipts-msc2409 branch (which extends the above branch) uses MSC2409 to detect when you read a bridged message on Matrix, so it can tell Puppeteer to view it on LINE on your behalf. This will let your LINE contacts know when youāve read their messages.
After this, only a few read receipt improvements are left to be made:
Make Puppeteer check all LINE chats (not just the most recently-used one) to see if messages you sent have been read (in LINE). This will work by cycling through all LINE chats where the final message is posted by you and doesnāt have a āReadā marker on it yet.
Use MSC2409 to avoid having to view a LINE chat when syncing non-text messages (like images). The idea is to send a placeholder message that will get replaced with the real message (which requires Puppeteer to view the LINE chat) only when you actually view the placeholder.
Iāve been slowly refactoring the room and communities list to prepare it for spaces. This work is now mostly complete, changing ~4000 lines of code, of which 1500 just got deleted. All of the sidebars are now expandable and collapsible, so you can see the full name of your tags and communities and the lists should also update more dynamically now. Startup also only takes half as long as before on my system and Nheko uses 100MB less memory for my account. Next week Iāll probably add spaces to the communities list as well as the room list.
Apart from that LorenDB has been rewriting the member list as well as the invite dialog in Qml and manu has been making progress on the room directory. All of that seems to be coming along nicely and behave much more reasonably than the old versions. There has also been a lot of progress on the Italian and Esperanto translations as well as a few smaller bug fixes and performance improvements.
I hope we will make it to space next week!
Element Clients
Updates from the teams.
Delight, a team aiming to delight users
Weāre making good progress on the ability to re-order Spaces on Web & Android, expected to land soon!
Weāre also adding aliases to Space creation, to make it easier to share and onboard other users
On iOS, we recently merged a refactor with a new sidebar design which lays the foundations for iOS joining the Spaces beta
Weāve also been working on adding pagination to the Space Summary API on Synapse
Meanwhile, weāre also shepherding various MSCs through the spec process to improve private Spaces in the very near future
Web
1.7.30 released on Monday
On develop
Upgraded to React 17
First GitHub Actions pipeline for web
In flight
Continuing to improve application performance
Adding dashboard for performance benchmarks
Working on Apple silicon desktop builds
Working on translation mismatch errors
iOS
1.4.1 released on Tuesday on the App Store
The new side menu and voice messages are coming.
We are setting up Towncrier to avoid merge conflicts on our CHANGES files. Those conflict prevent Github Actions, our CI, from starting
We fixed several annoying bugs regarding VoIP and app stability
Android
Element Android 1.1.9 has been pushed to production
We are working with the design team on the dark and light themes, not forgetting the black theme, to ensure some coherence across the application and also to clean up some legacy code. There were too many shades of greyā¦ We will also do the same work on TextAppearance.
This week was a busy week for NeoChat. We added tons of cool stuff! We rewrote the setting page to add a bit of organization in the settings. This also pushed us to add new appearance options. You can now add a blur effect as background, change the color scheme of NeoChat and switch between bubbles and a more compact layout as you wish.
Another thing we worked on was spellchecking. NeoChat will now add a small red underline under misspelled words and will suggest corrections. This is using the Sonnet frameworks and will integrates perfectly with your personal dictionary from your other KDE apps.
Finally something we added two weeks ago but forgot to mention, we added a quick room switcher using the Ctrl + K shortcut.
Another small release - libQuotient 0.6.7 is out, fixing an issue causing NeoChat to not add rooms to the roomlist after joining. Thanks to Carl Schwan for hunting the problem down!
Apparently my work-in-progress end-to-end-encryption implementation for libQuotient was bad enough to cause performance problems on my homeserver (Sorry about that!). This should be fixed now š
/relations request instead of 10s now takes 2s overall
Added a /servers api endpoint which returns all servers based on the room_ids. (It splits of the server_name from room_ids and puts them into an array)
Bug Fixes
Aliases with emoji will now get recognized.
Thanks to jo , Nico , joepie91 š³ļøāš and poljar for helping to archive these improvements and hinting where improvements were possible to be made :)
Dept of Guides š§
A guide for creating simple Matrix bots with Python and Simple-Matrix-Bot-Lib
Disclaimer: Low bandwidth Matrix is experimental, not yet standardised, and subject to change without notice.
This guide is for Matrix developers who want to support
MSC3079: Low Bandwidth CS API in their
clients/servers. Please read the experimental MSC if you want to learn more about what is happening
at a protocol level. If you want a high level overview of low bandwidth Matrix and why you should
care, watch the 12 minute demo on Matrix Live.
Matrix currently uses HTTP APIs with JSON data to communicate from the client to the server. This is
widely supported but is not very bandwidth efficient. This means that the protocol is slower, more
costly and less able to be used on low bandwidth links (e.g 2G networks) which are common in certain
parts of the world. MSC3079 defines a low bandwidth protocol using CoAP and CBOR instead of HTTP and
JSON respectively. In the future homeservers will natively support some form of low bandwidth
protocol. However, at present, no homeserver natively supports MSC3079. Therefore, this guide will
set up a low bandwidth proxy server which can be put in front of any Matrix homeserver
(Synapse, Dendrite, Conduit, etc) to make it MSC3079-compatible. This guide will also configure an
Android device to speak MSC3079.
Low bandwidth Matrix currently does not support web browsers due to their inability to send UDP
traffic. You do not need to be running a homeserver to follow this tutorial.
Setting up a low bandwidth proxy for your homeserver
Prerequisites:
Go 1.13+
openssl to generate a self-signed DTLS certificate, or an existing certificate you want to use.
Linux or Mac user
Steps:
Clone the repo: git clone https://github.com/matrix-org/lb.git
Build the low bandwidth proxy: go build ./cmd/proxy
Generate a elliptic curve DTLS key/certificate: (we use curve keys as they are smaller than RSA
keys, but both work.)
INFO[0000] Listening on :8008/tcp to reverse proxy from http://127.0.0.1:8008 to https://matrix-client.matrix.org - HTTPS enabled: false
INFO[0000] Listening for DTLS on :8008 - ACK piggyback period: 5s
Mac users: If you are having trouble generating EC certificates, make sure you are using OpenSSL and
not LibreSSL which comes by default: openssl version. To use OpenSSL, brew install openssl which
then dumps the binary to /usr/local/opt/openssl/bin/openssl.
To test it is working correctly:
Terminal window
# build command line tools we can use to act as a low bandwidth client
gobuild./cmd/jc
gobuild./cmd/coap
# do a CoAP GET request to matrix.org via the proxy
Check the proxy logs for errors (e.g bad hostname)
Try adding -v to ./coap (e.g bad method or path)
Run the proxy with SSLKEYLOGFILE=ssl.log and inspect the decrypted traffic using Wireshark.
Otherwise, congratulations! You now have a low bandwidth proxy! You can connect to your proxy just
like you would to matrix.org or any other homeserver.
Security considerations
The proxy acts as a man in the middle and can read all non-E2EE traffic, including login
credentials. DO NOT USE UNTRUSTED LOW BANDWIDTH PROXY SERVERS. Only use proxy servers run by
yourself or the homeserver admins.
Weāll add low bandwidth matrix to Element Android and iOS by default once itās standardised - but
while things are still experimental, hereās a guide for how to build Element Android to do it
yourself if you feel the urge. This can be used as inspiration for other Matrix clients too.
Prerequisites:
Android Studio
Steps:
Clone the repo: git clone https://github.com/vector-im/element-android.git
Checkout kegan/lb: git checkout kegan/lb. This branch replaces all HTTP traffic going to
/_matrix/client/* with LB traffic. /_matrix/media traffic is left untouched. This branch also
disables TLS checks entirely so self-signed certificates will work.
Clone the low bandwidth repo if you havenāt already:
git clone https://github.com/matrix-org/lb.git
In the low bandwidth repo, build the mobile bindings:
go get golang.org/x/mobile/cmd/gomobile
cd mobile
# if gomobile isn't on your path, then ~/go/bin/gomobile
gomobile bind -target=android
Copy the output files to a directory in the Element Android repo which Gradle will pick up:
Configure the proxyās --advertise address. If you are running on a local device, restart the
proxy with an --advertise of your machines LAN IP e.g 192.168.1.2 instead of 127.0.0.1.
If you are running on an emulator, restart the proxy with an --advertise of the
host IP:
10.0.2.2. The URL scheme should be https not http, else image loading wonāt work as Element
Android wonāt download media over http.
Login to your matrix.org account via the proxy with the --advertise address as the HS URL
e.g https://192.168.1.2:8008 or https://10.0.2.2:8008. The port is important.
To verify it is running via low bandwidth:
Install Wireshark.
Restart the proxy with the environment variable SSLKEYLOGFILE=ssl.log.
Run tcpdump on the right interface e.g: sudo tcpdump -i en0 -s 0 -v port 8008 -w lb.pcap
Force stop the android app to forcibly close any existing DTLS connections.
Re-open the app.
Open lb.pcap in Wireshark and set ssl.log as the Pre-Master Secret log filename via
Preferences -> Protocols -> TLS -> Pre-Master Secret log filename.
Check there is DTLS/CoAP traffic.
Performance
To send a single āHello Worldā message to /room/$room_id/send/m.room.message/$txn_id
and receive the response, including connection setup:
Protocol
Num packets
Total bytes
HTTP2+JSON
43
6533
CoAP+CBOR
6
1440
Limitations
CoAP OBSERVE is not enabled by default.
This extension allows the server to push data to the client so the client doesnāt need to
long-poll. It is not yet enabled because of the risk of state synchronisation issues between the
proxy and the client. If the proxy gets restarted, the client will not receive sync updates
until it refreshes its subscription, which happens infrequently. During this time the client
is not aware that anything is wrong.
CoAP uses Blockwise Transfer to download
large responses. Each block must be ACKed before the next block can be sent. This is less
efficient than TCP which has a Receive Window which allows multiple in-flight packets at
once. This means CoAP is worse at downloading large responses, requiring more round trips
to completely send the data.
The current version of /sync sends back much more data than is strictly necessary. This
means the initial sync can be slower than expected. On a low kbps link this can flood the
network with so much data that the sync stream begins to fall behind. Future work will look
to optimise the sync API.
