Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Element did coordinate with the F-Droid packagers on behalf of both Element Android and SchildiChat.
Because F-Droid runs their own builds and requires published source code, there is no current mechanism for pre-building and staging security releases for issues which are not yet publicly disclosed.
That said, the packager was extremely helpful and prepared the metadata updates in advance to ensure that both applications could enter the build queue as quickly as possible upon release:
- Element 1.2.2: https://gitlab.com/fdroid/fdroiddata/-/commit/76c8f5b87aa8df...
- SchildiChat 1.2.2.sc43: https://gitlab.com/fdroid/fdroiddata/-/commit/232b316f8affe0...
The current way we're approaching this is to split the reference E2EE implementation into its own rust crate (https://github.com/matrix-org/matrix-rust-sdk/tree/master/ma...) which can be used with any SDK (e.g. we're almost finished embedding it into the Kotlin matrix-android-sdk2 client)
Separately, there's also the overall matrix-rust-sdk https://github.com/matrix-org/matrix-rust-sdk for clients to use as a "full fat" Matrix client SDK - as used by Fractal Next (https://gitlab.gnome.org/GNOME/fractal/-/tree/fractal-next) etc. We might end up using this in Element too in future (especially in Element iOS, where a Swift UI + matrix-rust-sdk backend could be quite a cute next generation architecture).
So while the first generation reference Matrix SDKs (matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk) were completely independent implementations, each with their own bugs and increased audit surface, we're hoping that matrix-rust-sdk will simplify this a lot in future.
Synapse is the server to start with https://github.com/matrix-org/synapse/
From there, what's the first place to find people to chat? I don't have a good answer there, but the 'rooms' functionality is a nice way to group communities.
This is a great example of why key-sharing exists today... and why it shouldn't. In theory, you should be able to pick up and old client and decrypt new messages and history on it absolutely fine. However, in practice, Matrix's E2EE publishes 100 one-time keys (OTKs) on your server to let other devices establish secure 1:1 channels with you if you're offline - and if you go offline and that pool of OTKs exhausts, then new sessions won't get set up and you won't receive keys for new messages... giving the misbehaviour you're seeing.
Now, you're right that key-sharing is a useful way to fudge around that failure mode.
But an even better way to fix it would be to find a way to stop the OTK pool exhausting - and that's precisely what MSC2732 is: https://github.com/uhoreg/matrix-doc/blob/fallback_keys/prop.... This provides a last-ditch key which can be used to set up 1:1 sessions even if you run out of OTKs, which is marginally inferior to using a different OTK every time, but in practice really isn't a disaster (see the MSC for details).
However, fallback keys are relatively new and aren't implemented on all clients yet (matrix-js-sdk has them, but matrix-ios-sdk is implementing this coincidentally this week)... and so until they land, we still need keyshare requests to paper over this limitation.
But in future, hopefully it will be almost unheard-of to need a keyshare request, and we can change them to be an entirely manual or out-of-hand mechanism of some kind, and avoid classes of bugs like the vuln in question here in future.
It wasn't designed exclusively as a federated network, tbh - we've been planning for P2P since pretty much day one; https://matrix.org/~matthew/2016-12-22%20Matrix%20Balancing%... is a talk I gave in 2015 when Matrix was less than a year old on our plans to go P2P.
Personally, I think it's really nice that in P2P Matrix precisely the same client-server API is used as for normal Matrix, so all the work that goes into the Matrix client and E2EE etc is preserved without any changes at all. Instead, it just talks to a server running on localhost, which then replicates traffic around over the P2P overlay (in future using store-and-forward servers if the target server is offline). It's really not a bunch of hacks, thanks to Matrix being architected to make the replication transport & protocol pluggable from the outset.
One of our primary goals on the Synapse last quarter was to make it possible for a new homeserver to join Matrix HQ (a large, public room) in under 1 GB of RAM. And we did it. https://matrix.org/blog/2021/06/15/synapse-1-36-0-released
It's not the slimmest beast, in part because Synapse needs to scale up to country-scale deployments, but its ability to scale down has significantly improved over the past year.
That said, Dendrite and Conduit (https://gitlab.com/famedly/conduit/) are exciting projects which will optimize for different operational contexts.
Have you thought about hosting your own F-Droid repository, like NewPipe does?