On Monday (2018-06-11) we had an incident where #matrix:matrix.org was hijacked by a malicious user pretending to join the room immediately after its creation in 2014 and then setting an m.room.power_levels event ‘before' the correct initial power_level for the room.
Under normal circumstances this should be impossible because the initial m.room.power_levels for a room should be set before its m.room.join_rules event, meaning users who join the room are subject to its power levels. However, back before we'd even released Synapse, the first two rooms ever created in Matrix (#test:matrix.org and #matrix:matrix.org) were manually created and set the join_rules before the power_levels event, letting users join before the room's power_levels were defined, and so were vulnerable to this attack. We've since re-created #matrix:matrix.org - please re-/join the room if you haven't already!
As a defensive measure, we are releasing a security update of Synapse (0.31.2) today which changes the rules used to authenticate power_level events, such that we fail-safe rather than fail-deadly if the existing auth mechanisms fail. In practice this means changing the default power level required to set state to be 50 rather than 0 if there is no power_levels event present, thus meaning that only the room creator can set the initial power_levels event.
We are not aware of anyone abusing this (other than the old #matrix:matrix.org room) but we'd rather be safe than sorry, so would recommend that everyone upgrade as soon as possible.
This of course constitutes a change to the spec, so full technical details and ongoing discussion around the Matrix Spec Change proposal can be followed over at MSC1304.
EDIT: if you are aware of your server participating in rooms whose first power_levels event is deliberately set by a different user to their creator, please let us know asap (and don't upgrade!)
This work is all part of a general push to finalise and harden and fully specify the Server-Server API as we push towards a long-awaited stable release of Matrix!
SECURITY UPDATE: Prevent unauthorised users from setting state events in a room when there is no m.room.power_levels event in force in the room. (PR #3397)
I am working on implementing end-to-end encryption in the Python SDK. As of now, I have done a good part of the encryption and decryption work with Olm and Megolm, enough to allow communicating with Riot in an encrypted room. My next goals include device list tracking and key persistence, which are the main steps left before the implementation starts being usable in a real environment.
My aim is to achieve feature completion on Dendrite. Have got lots of help from anoa, for which I'm very grateful.
Features worked on this month:
we made a transactions cache/table for idempotency. So now dendrite will not reprocess events as far as client-server api is concerned.
added request authentication function which recognises an application service user (partially landed.)
username auto generation, which let's you register without username (will be used for guest access later.)
We also added a tokens library based on macaroons, however we might not be using it anytime soon. Since it's been known to be very problematic (on synapse).
kitsune has announced GTAD v0.6 and libQMatrixClient v0.3. We've covered GTAD before, but I think it's worth including this note from the readme:
GTAD (Generate Things from an API Description) is a generator of code from a Swagger/OpenAPI specification. Initially made to generate marshalling/unmarshalling C++ code for Matrix CS API, it can be extended to support other API descriptions and other programming languages with static type checking.
A new version of API code generator, GTAD, 0.6, has been released today, adding support of variant types, proper dealing with definitions referencing other files ($ref) and more options to override schema names - even defined inline. Most importantly, GTAD has got extensive README.md that describes (most of) the things needed to start writing your own templates! As usual, kitsune will be happy to help those who would like to try it (both with C/C++ projects and other languages).
libQMatrixClient has been benefiting from GTAD over the last 4 months or so - but this is the first release where GTAD is stable and feature-complete enough to be shared with other projects.
A new version of libQMatrixClient, 0.3, comes out this weekend. This is the first libQMatrixClient release to include (almost) all CS API requests and supplementary (non-event) definitions, thanks to GTAD 0.6. Notably, it now includes jobs to register users, manage devices and keys on the server (no local key management yet - E2E work has just begun). This version also gains centralised request error handling so that clients could deal with problems in a unified way, and support "Consent not given" errors of GDPR fame, so that client authors could automatically open consent pages. You can also trigger logging out of all devices through libQMatrixClient thanks to a very recent addition to CS API spec from TravisR.
We have been working on Riot stability: fixing crashes and adding more tools to control code quality
The community on android adds a more readable display of keys and a floating actions menu is coming.
We've got a shiny new application service component which runs as a separate process (if you're doing multiprocess dendrite) that handles all outbound communication to application services. Last week I got event sending working. This week I'm hooking up an internal API for other components (roomserver, c-s api) to talk to the app service component, as we occasionally need to ping AS's to ask about existence of rooms or users. Getting those two endpoints covered is the goal of this week.
ma1uta appeared with an extremely ambitious piece of work. His goal:
I want to create a full spec's implementation on java (all 5 specification). After that I want try to write a homeserver (2 variants: distributed on java+kafka and simple which can run on a light vps). But it's a long-term goal.
So far work has begun on an implementation of the Matrix API in Java:
https://gitlab.com/ma1uta/jeon - another java implementation of the matrix api (client-server, server-server, application server, push server, identity server) using jax-ws. It corresponds the specification on https://matrix.org/docs/spec. On the next step I want dive deep into synapse to parse it's api and fill the gaps of the spec with sending pull request. May be I will write something like a TCK (test compatibility kit).
And an SDK for which there is a sample bot for mastodon:
Also this project has a very early sdk (client, bot). I will fix it after finishing works with the spec.
https://gitlab.com/ma1uta/mxtoot - matrix-mastodon bridge.
With this bridge you can invite a bot and read your home mastodon's timeline, post messages, reply and boost messages.
There are rooms to follow progress on these projects:
t3chguy, straight out of exams, went back to working on matrix-search, now with a working release, including e2e chats!
a local Full Text Search engine for Matrix, which will index the events locally and then provide a search api interface for matrix clients to query it
matrix-search mimics the standard /search API
Switched the Kubernetes-oriented Synapse image over to running on the official one as a base, seems to still work quite well. Even if there were some issues at first due to Alpine and busybox.
I've been building slightly specialized Synapse docker images since 0.25.1 - and running them on my Kubernetes cluster at home. Moved them to being based on the official images now instead of building them on CentOS as I used to.
Most notable change from v0.30.0 is to switch to python prometheus library to improve system stats reporting. WARNING this changes a number of prometheus metrics in a backwards-incompatible manner.
There are still many changes being made relating to the Python 3 migration.
I'm going to start making a list of guides from around the web to be linked from https://matrix.org. If you have, or know of, useful guides relating to matrix, please let me know or share in #twim:matrix.org.
And here it is. As you may have noticed, I'm leaning much more toward quoting wherever possible, rather than trying to paraphrase. The aim is to keep the content authentic and community-driven, rather than a narrative from one fairly naive observer. The risk is it makes the post awkward to read as it switches voice too frequently. Come to #twim:matrix.org and let me know if you have opinions on this.
With the core team focusing on upcoming performance work and GDPR management tooling, v0.31.0 is most notable for improvements to system stats. Additionally, work continues on our py3 port and a host of small bug fixes and perf improvements.
Most notable change from v0.30.0 is to switch to python prometheus library to improve system stats reporting. WARNING this changes a number of prometheus metrics in a backwards-incompatible manner. For more details, seedocs/metrics-howto.rst
hawkowl is technically new to the Matrix Core team but is already integrated and storming the codebase like an old pro. She and notafile have been ramping up on work to the make the Synapse codebase work with Python 3.
🔗matrix-docker-ansible-deploy can now set up your homeserver using the official Matrix Synapse Docker image
Using this Ansible playbook is probably the easiest way to set up a fully-functioning Matrix homeserver on your own machine. The setup includes Matrix Synapse and some related services required to actually make it useful (automatically-managed HTTPS; STUN/TURN server for audio/video calls; Postgres database for Synapse; optionally riot-web; optionally Amazon S3 storage support)
my personal problem was:
i didn't want to open up registration for everyone
i didn't want to register every account manually and have to worry about seeing passwords etc
now i can just share a link, e.g:
https://zeratax.github.io/matrix-registration/demo.html?token=JargonGingerYankee
and my friends can register.
these token can be restricted as one time usable only or by an expiration date.
Last week dendrite was filtering events from user's into separate queues for each application service to eventually be given. Sending these events requires batching them up into transactions and then sending them to an HTTP endpoint on the application service. I'm happy to report that from today, that functionality is now implemented, along with graceful handling of both server and application service downtime.
Fractal got the beginning of a revamped directory (from one of our GSoC interns), as well as misc bugfixes and performance improvements. It has also been added to Damned lies, the GNOME platform for translations.
Riot is undergoing a visual redesign, thanks to Jouni Helminen. Take a look at the redesign work on the Riot blog. The changes are not radical, but will help standardise and modernise the Riot interface. Early feedback I've seen has been mostly positive.
The user can now change the following settings: Avatar, display name, add and remove email addresses and phone numbers. Also, they can see the homeserver and their own MXID. We will probably make some more small changes on the way to make the UX as good as we possibly can.
Fractal was featured in Fedora Magazine this week, just a little introduction. I notice the article barely introduces matrix: not sure if that's an oversight or a belief that the audience will already know it!
Still posting about spec proposals. To get involved in the spec development process, take a look at the Matrix Spec Change Proposals page to find out what's happening, read the proposals, then talk about it in #matrix-spec:matrix.org. One proposal looking for attention and a good place to start:
🔗Interactive Key Verification: Spec proposal from uhoreg
As mentioned in our last blog post on GDPR, to make sure that everyone has read and understood the important details about how their personal data is processed by the matrix.org homeserver, users who haven't yet agreed to the privacy notice and terms and conditions will be blocked from sending new messages until they have.
Users will continue to be able to receive messages, so they won't miss out on any messages sent to them before they've agreed to the terms.
The System Alerts room has already sent every user their unique link to review and agree, and if anyone missed that message, the latest Riot.im web and mobile will display a helpful error message guiding users who are yet to agree through the agreement process.
If you have any questions or difficulties, please let us know at [email protected].
If you've connected to the matrix.org homeserver today, you'll have noticed some activity in support of GDPR compliance. The most obvious of these is an invite from System Alerts (aka @server:matrix.org):
We've rolled out the System Alerts feature to communicate important platform information to all of a homeserver's users. Today, we're using it to communicate the arrival of our new (and much-improved) Privacy Notice and Terms and Conditions to users on matrix.org.
The System Alerts service takes the form of an (unrejectable) invite to a room. We took this approach to support maximum compatibility with the myriad Matrix clients (since all Matrix clients can support conversations in a room ?).
When we first rolled out System Alerts, we didn't allow users leave the System Alerts room. Sorry! We got a bit overexcited - we've fixed that now (though please do provide your agreement before you leave).
At some point today the System Alerts service will provide you with unique link, directing you to review the new terms and provide your agreement.
For us to process your personal data lawfully, it's really important that we know you understand and agree to our Privacy Notice and Terms and Conditions. For that reason, we will shortly be blocking any users who haven't indicated their acceptance, so please act quickly when you receive your link.
Once the block is enabled, users who haven't accepted the terms will see an error when they try and send a message, join a room, or send an invite. This message will also include the unique link to review and accept the terms, so users who haven't seen the message from System Alerts will know what to do.
Don't worry if you're reading this some time after May 25 - accepting the terms at any time will unblock message sending on your account, and you won't have missed any messages sent to you.
If you have any thoughts or suggestions on the legal documentation, you can provide comment via github.
Folks are already accepting the new policies - thanks.
We're going to start requiring acceptance to access the matrix.org server on Tuesday (May 29th).
We're already receiving our first GDPR requests… :|
Erasure and Right-to-be-forgotten work (Phase 2) is next up so we can action the requests in a timely manner.
It looks like we will go ahead on removing MXIDs on events as a Phase 3 (although for now we do warn people that this is effectively a technical limitation of Matrix, albeit one that we're working on).
Big E2E progress from mujx, developer of the nheko client on his project mtxclient. As of this week, mxtclient is able to decrypt group events. When writing (that is, sending encrypted messages) is complete, the idea is to migrate this work back to nheko, though mujx points out this library could be used in any client.
JonTheNiceGuy produced a helpful video describing how to use bridges for IRC, Slack and Telegram, showing the difference between the different bridges. I found this to be really clear and well-paced for following the many practical details of bridging. Watch here: https://www.youtube.com/watch?v=ZNEzgYRLj8g
"finished edit passing between Discord and Matrix, as well as support for discord's custom emojis (though UX is a bit manual until TravisR's proposal goes through ?)"
This small tool will take the local part of the room ID created by the Matrix<>Facebook Messenger bot once the friend has joined it, identify th friend, and grab their avatar and display name to set the room's.
betz runs the https://hackerspaces.be/ matrix server and has this week, inbetween repairing his Synapse install, been working on a project called matrixboard. This tool is used to output the last five messages from a given room to displayed as HTML, the idea being to display output from a specific room as a website widget. You can see an example using #matrix-devhere.
The idea of using the room state to encapsulate bot data per-room was well received, discussion in #TWIM:matrix.org suggests this is an estabilished practice for some developers.
No general GSOC round-up this week, &Adam shared the news that GSOC-student Zil0's first PR towards E2E in matrix-python-sdk landed on master. These PRs are working from efforts previously contributed by pik.
Work continues in the Ruma space. This week saw the release of
ruma-events0.10.0: ruma-events contains Serializable Rust types for the events in the Matrix specification. 0.10.0 sees a major update with code provided by mujx, and contains many breaking changes.
f0x has started work on a tool to help migrate accounts - including across homeservers. Right now he's working on the GUI, but check out progress at https://github.com/f0x52/matrix-migrate.
As part of my master's thesis, I wrote the DSN Traveller bot, which is crawling the matrix federation to measure the shape and size of the matrix network, and how distributed it currently is. The bot is already in a smaller number of rooms for testing, and will join the remaining rooms over the next days. All details at https://dsn-traveller.dsn.scc.kit.edu/, room at #dsn-traveller:dsn-traveller.dsn.scc.kit.edu.
Anoa is on the case, having joined the core team on Monday - Dendrite is already sending events to ASes! Meanwhile APwhitehat is hacking away on his GSoC projects!
Last week I promised an update on the state of the various GSOC projects in the Matrix Ecosystem. There is activity happening but other than what's been discussed above we'll wait a week or two for more detailed updates.
As always, if you have things to say, projects to advertise, or anything else, ping me or visit #TWIM:matrix.org. I'm keen to get everyone included and keep this community enthused about all the work going on in the Matrix ecosystem.
v0.30.0 sees the introduction of Server Notices, which provides a channel whereby server administrators can send messages to users on the server, as well as Consent Management for tracking whether users have agreed to the terms and conditions set by the administrator of a server - and blocking access to the server until they have.
In conjunction these features support GDPR compliance in the form of providing a client agnostic means to contact users and ask for consent/agreement to a Privacy Notice.
For more information about our approach to GDPR compliance take a look here (although be aware that our position has evolved a bit; see the upcoming new privacy policy for the Matrix.org homeserver for details).
Additionally there are a host of bug fixes and refactors as well as an enhancement to our Dockerfile.
'Server Notices' are a new feature introduced in Synapse 0.30. They provide a
channel whereby server administrators can send messages to users on the server.
They are used as part of communication of the server policies (see Consent Tracking),
however the intention is that they may also find a use for features such
as "Message of the day".
This feature is specific to Synapse, but uses standard Matrix communication mechanisms,
so should work with any Matrix client. For more details see here.
Further Server Notices/Consent Tracking Support:
Allow overriding the server_notices user's avatar (PR #3273)
It's release time people, not to be outdone by our friends on the Riot web team, Synapse v0.29.1 lands today.
v0.29.1 contains an officially supported docker image (many thanks to the contribution from @kaiyou), continued progress towards Python 3 (thanks to @NotAFile) - as well as a heap of refactorings and bug fixes.
Something worth noting is a potentially breaking change in the error code that /login returns in the Client Server API. Details follow, but the change closes a gap between Synapse behaviour and the spec.
We'd like to give huge thanks to Silvio Fricke and Andreas Peters for writing and maintaining Synapse's first Dockerfile, as well as allmende, jcgruenhage, ptman, and ilianaw for theirs! The new Dockerfile from kaiyou has ended up being merged into the main synapse tree and we're going to try to maintain it going forwards, but folks should use whichever one they prefer.
Make Client-Server API return 401 for invalid token (PR #3161).This changes the Client-server spec to return a 401 error code instead of 403 when the access token is unrecognised. This is the behaviour required by the specification, but some clients may be relying on the old, incorrect behaviour.Thanks to @NotAFile for fixing this.
Features:
Add a Dockerfile for synapse (PR #2846) Thanks to @kaiyou!
Changes - General:
nuke-room-from-db.sh: added postgresql option and help (PR #2337) Thanks to @rubo77!
Part user from rooms on account deactivate (PR #3201)
Make 'unexpected logging context' into warnings (PR #3007)
