11 ms·

Disclosing E2EE vulnerability in multiple Matrix clients

333 points by Sami_Lehtinen 5y ago

criticaltinker 5y ago
> This is not a protocol or specification bug, but an implementation bug which was then unfortunately replicated in other independent implementations. > We will also accelerate our work on matrix-rust-sdk as a portable reference implementation of the Matrix protocol, avoiding the implicit requirement that each independent library must necessarily reimplement this logic on its own I like the idea of providing a core Rust/C++ library that can be called in any other runtime via FFI, compiling to WebAssembly, etc. I've used the same technique to ensure consistency in usage of a custom time-series compression format across an organization. Overall this technique seems in-line with the "DRY" principle, and the tradeoffs have been favorable in my experience. I think it will be a good step forward for the Matrix ecosystem.
- Arathorn 5y ago
  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/matrix_sdk_crypto 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 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 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.
  - danShumway 5y ago
    Quick comment, just want to show some additional support for the shared crate approach that Matrix is pursuing, it should give people a lot more confidence to try alternate clients. I throw messaging apps in the same category as, for example, web browsers. It's really tough to try an alternate implementation if you're worried that they might have broken a complicated security feature. So having more shared crates mitigates some of that risk.
jaimehrubiks 5y ago
Any recommendation to get started with matrix? Like use cases, featured clients, interesting public chats, or similar? To someone whose close environment does not use it
- zeroping 5y ago
  The reference clients and server are a good place to start. They're the place to find all the protocol features implemented and well supported. The Element client (desktop/web/android) is electron-based https://element.io/get-started https://element.io/get-started Synapse is the server to start with https://github.com/matrix-org/synapse/ 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 'spaces' functionality is a nice way to group communities.
  - preya2k 5y ago
    I assume you meant the “spaces” functionality to group rooms?
    - zeroping 5y ago
      D'oh, yes I did. Thanks.
- galbar 5y ago
  I started by setting up a synapse server (with docker it is quite easy, although reading all the config options takes some time). I already had a server with docker services running there, so deploying an extra container was easy for me. I started trying it, with the Element.io apps and convinced a techy friend to try it. Since then, he set up his own server and we have a group of friends that we mainly communicate through matrix. Also, I try to use it with my parents. They want to use it, but end up writing to me through WhatsApp out of muscle memory. After some time I started looking at public rooms that I'd be interested into, available in matrix.org or matrix.feneas.org. The easiest way to start, though, is to create a free account in the matrix.org public server using the webapp[0]. [0]: https://app.element.io/#/register https://app.element.io/#/register
fouc 5y ago
> trick vulnerable clients into disclosing encryption keys for messages previously sent by that client to user accounts later compromised by an attacker. Doesn't the fact there's some kind of mechanism or expectation of sending encryption keys willy nilly imply a flaw with the protocol perhaps?
- pkulak 5y ago
  > willy nilly It's not though. The fix is to cryptographically verify requesting clients before sending.
- aidenn0 5y ago
  They address this in the last two paragraphs of the article.
- Joe_Cool 5y ago
  If "send key to all members of channel x" is enabled it would be good if that would work. You can set it to "only other clients and people I have personally verified" but that is quite cumbersome for big channels that just don't want clear text.
pkulak 5y ago
I'm a tad worried about getting rid of key-sharing. I seem to use this every once in a while. Pretty much any time I use a client I haven't used in a while. I guess I could just get the keys from the backup, but then I need to have THAT key, which is a bit inconvenient.
- Arathorn 5y ago
  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/proposals/2732-olm-fallback-keys.md 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.
  - pkulak 5y ago
    Thank you for writing that all out. I wasn't familiar with most of these details.
  - criticaltinker 5y ago
    > 100 one-time keys (OTKs) on your server Is 100 a safe default for devices with limited memory, or are there other more salient constraints that I'm ignorant of?
xiaomai 5y ago
What are people using for a self-hosted "slack" type messenger these days? I have looked at Matrix (which I am interested in but I think needs time to settle right now), Zulip (I really like their threading model but it has been confusing for other people I have tried it with), Rocket chat (only recently aware of this one). What else is there? Anyone have good/bad experiences with any of these?
- cyberlurker 5y ago
  Mattermost is okay
  - dbrgn 5y ago
    Yeah, I have good experiences with Mattermost (bundled with GitLab) as chat for a hackerspace/makerspace. As long as you're OK with unencrypted push messages, building your own version of the app and keeping it up to date is horrible. (React native levels of horrible.)
- mxuribe 5y ago
  > ...I think needs time to settle right now... I hear this on occasion (though more rarer nowadays than in the past)...But curious, is there something specific that you're finding in matrix that is not yet settled? By all means, the beauty of open source stuff is that you get to choose whether you (and your circle of contacts) uses zulip, mattermost, etc...So, i encourage you to use whatever open source offering gives you (and your circle of contacts) what is needed/desired. But with me being such a fanboy of matrix, i always get curious. Would you care to share specifics?
- agentdrtran 5y ago
  That's basically it. A lot of options but they all have some flaw. Rocket Chat and mattermost both lock features behind an enterprise paywall (although Rocket Chat is more forgiving and has optional E2EE), Zulip is nice but still a small player and some people aren't fans of the UX, and Matrix lacks the polish of slack and moderation tools are not up to speed with Slack/RC/Mattermost, which is a problem for larger groups.
remram 5y ago
> Matrix supports the concept of “key sharing”, letting a Matrix client which lacks the keys to decrypt a message request those keys from that user's other devices or the original sender's device. I'm a bit curious why you'd ever need to request those keys from somebody else, in addition to your own devices (or your homeserver, where they'd be stored encrypted by a key known by your own devices).
- Youden 5y ago
  Imagine you're a "normal" person who has a phone and doesn't really use a computer. You lose your phone and want to retrieve the history of a chat you had with your friend on the new phone. You ask your friend to send the key to your new device.
  - remram 5y ago
    That sounds like a manual process that would not be part of the automated "key sharing" functionality as described.
- Arathorn 5y ago
  The recommendation is that devices only accept requests to share (forward) keys from a) other devices belonging to that user, b) the device which originally send the message. It's acceptable to gossip keys between your own devices (assuming you authenticate them correctly!) given... they're all your own devices. It's also acceptable to request the sender to re-send the keys to you, given the sender knows for sure whether you were allowed to receive the key (given it made that choice in the first place). It's not acceptable to request keys from other devices in the room, as they won't necessarily know whether you were actually allowed to receive the message key you're requesting - only the sender knows for sure whether it should have been sent to you; it was their key after all. Plus it would risk make vulnerabilities like the one in question here even worse, given anyone could try to exfiltrate messages from anyone else, rather than "just" the sender (as was the case here).
nightpool 5y ago
With the recent dust-up around protonmail's "end-to-end encryption", it's hard for me to believe that the hammer isn't going to come down on Matrix in a similar way. Nobody has seriously turned their attention to the compromised-homeserver issue, even though that's the only threat model under which e2ee makes sense. Expecting users in hundred-person group chats to manually verify each other individual user's keys is nonsensical. And even a single unverified key means that their homeserver operator could be listening in. I feel like Matrix should move more towards emphasizing how easy it is to self-host and maintain control of your own Matrix data, making e2ee is a non-issue.
- COGlory 5y ago
  What dustup around end-to-end encryption? I'm only familiar with ProtonMail's IP logging controversy. I was unaware it impacted E2E at all?
  - deleted 5y ago
    [deleted]
  - abnercoimbre 5y ago
    Did you find further information? Would've been nice for the GP to point to a source or news item.
  - 0xdeadb00f 5y ago
    I'm pretty sure OP is just misinformed. That, or they're talking about that one huge hole in PM's PGP implementation years and years ago.
  - nightpool 5y ago
    Right, the dust-up was "PM advertises their service as secure and end-to-end encrypted, but in practice that doesn't mean much because user access is non-anonymous and they're still a central metadata honeypot for any law enforcement agency to log accesses to" (compared to e.g. Signal which AIUI is designed as an anonymous dropbox so that Signal can't correlate between user access to their servers and individual senders)
m-p-3 5y ago
Still haven't received the up-to-date version from F-Droid, which is still stuck at 1.2.0. They really should have some provision to expedite a release when a serious security flaw is discovered. Not the Matrix team's fault, but still a bit worrying. Maybe they could implement their own F-Droid repo to skip the F-Droid build server?
- progval 5y ago
  Or they could coordinate with the F-Droid packagers, like they did for other distributions. (Actually they might have, since they don't exhaustively list them)
  - callahad 5y ago
    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 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/76c8f5b87aa8dfc508b97805602c9496e2233a00 https://gitlab.com/fdroid/fdroiddata/-/commit/76c8f5b87aa8df... - SchildiChat 1.2.2.sc43: https://gitlab.com/fdroid/fdroiddata/-/commit/232b316f8affe0e538d0769c92fa3564b9c488e2 https://gitlab.com/fdroid/fdroiddata/-/commit/232b316f8affe0...
    - nybble41 5y ago
      > Because F-Droid runs their own builds and requires published source code, … That seems… completely reasonable for distributors of open-source projects. Mandatory, even, for compliance many open-source licenses. Are you saying there are other open source repositories (e.g. Linux distros) which would not require published source code before distributing binaries?
      - callahad 5y ago
deleted 5y ago
[deleted]
ncmncm 5y ago
In other news, Nheko supports E2EE.
Sami_Lehtinen 5y ago
Quote from the original documentation: "The recommended strategy is to share the keys automatically only to verified devices of the same user. Requests coming from unverified devices should prompt a dialog, allowing the user to verify the device, share the keys without verifying, or not to share them (and ignore future requests). A client should also check whether requests coming from devices of other users are legitimate." - It made me smile, because should and recommended doesn't generally mean anything to developers. Only mandatory, must and must not, sections might get some attention.
jeroenhd 5y ago
> As discussed above, key sharing was originally introduced to make E2EE more reliable while we were ironing out its many edge cases and failure modes. Based on what I understand about this feature, I've had to rely on key sharing quite often (even requiring manually requesting keys a bunch of times) for E2EE to work reliably. I worry that my experience will be severely degraded if key sharing ends up being removed from the protocol. Having the sending party re-encrypt messages for a new device require the other party to be online. I can see that requirement not being met in several ways, e.g. if the other party dies or uninstalls the application, or when the other end is arrested (I can imagine journalists losing access to activists' messages because of this).
- Arathorn 5y ago
  > I've had to rely on key sharing quite often (even requiring manually requesting keys a bunch of times) for E2EE to work reliably. This is because it's papering over edge cases in E2EE. > Having the sending party re-encrypt messages for a new device require the other party to be online We never make senders re-encrypt messages like this, and we never would. Firstly, key-sharing from the sender does require the other party to be online already. Otherwise, if you have the keys in an existing device, you could get them onto your new device by backing them up on the server - or using "dehydrated" devices; where the 'new' device you log into is actually one which is stored encrypted on the server, and "re-hydrated" into a new device when you login... and so already has your keys. These have security trade-offs obviously (what if your online backup gets pwned? what if your dehydrated device gets pwned?) but it's not obviously worse than exfiltrating the missing keys from the sender.

333 points by Sami_Lehtinen 5y ago

> This is not a protocol or specification bug, but an implementation bug which was then unfortunately replicated in other independent implementations. > We will also accelerate our work on matrix-rust-sdk as a portable reference implementation of the Matrix protocol, avoiding the implicit requirement that each independent library must necessarily reimplement this logic on its own I like the idea of providing a core Rust/C++ library that can be called in any other runtime via FFI, compiling to WebAssembly, etc. I've used the same technique to ensure consistency in usage of a custom time-series compression format across an organization. Overall this technique seems in-line with the "DRY" principle, and the tradeoffs have been favorable in my experience. I think it will be a good step forward for the Matrix ecosystem.

Arathorn 5y ago
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/matrix_sdk_crypto 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 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 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.
- danShumway 5y ago
  Quick comment, just want to show some additional support for the shared crate approach that Matrix is pursuing, it should give people a lot more confidence to try alternate clients. I throw messaging apps in the same category as, for example, web browsers. It's really tough to try an alternate implementation if you're worried that they might have broken a complicated security feature. So having more shared crates mitigates some of that risk.

jaimehrubiks 5y ago

Any recommendation to get started with matrix? Like use cases, featured clients, interesting public chats, or similar? To someone whose close environment does not use it

zeroping 5y ago
The reference clients and server are a good place to start. They're the place to find all the protocol features implemented and well supported. The Element client (desktop/web/android) is electron-based https://element.io/get-started https://element.io/get-started Synapse is the server to start with https://github.com/matrix-org/synapse/ 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 'spaces' functionality is a nice way to group communities.
- preya2k 5y ago
  I assume you meant the “spaces” functionality to group rooms?
  - zeroping 5y ago
    D'oh, yes I did. Thanks.
galbar 5y ago
I started by setting up a synapse server (with docker it is quite easy, although reading all the config options takes some time). I already had a server with docker services running there, so deploying an extra container was easy for me. I started trying it, with the Element.io apps and convinced a techy friend to try it. Since then, he set up his own server and we have a group of friends that we mainly communicate through matrix. Also, I try to use it with my parents. They want to use it, but end up writing to me through WhatsApp out of muscle memory. After some time I started looking at public rooms that I'd be interested into, available in matrix.org or matrix.feneas.org. The easiest way to start, though, is to create a free account in the matrix.org public server using the webapp[0]. [0]: https://app.element.io/#/register https://app.element.io/#/register

fouc 5y ago

> trick vulnerable clients into disclosing encryption keys for messages previously sent by that client to user accounts later compromised by an attacker. Doesn't the fact there's some kind of mechanism or expectation of sending encryption keys willy nilly imply a flaw with the protocol perhaps?

pkulak 5y ago
> willy nilly It's not though. The fix is to cryptographically verify requesting clients before sending.
aidenn0 5y ago
They address this in the last two paragraphs of the article.
Joe_Cool 5y ago
If "send key to all members of channel x" is enabled it would be good if that would work. You can set it to "only other clients and people I have personally verified" but that is quite cumbersome for big channels that just don't want clear text.

pkulak 5y ago

I'm a tad worried about getting rid of key-sharing. I seem to use this every once in a while. Pretty much any time I use a client I haven't used in a while. I guess I could just get the keys from the backup, but then I need to have THAT key, which is a bit inconvenient.

Arathorn 5y ago
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/proposals/2732-olm-fallback-keys.md 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.
- pkulak 5y ago
  Thank you for writing that all out. I wasn't familiar with most of these details.
- criticaltinker 5y ago
  > 100 one-time keys (OTKs) on your server Is 100 a safe default for devices with limited memory, or are there other more salient constraints that I'm ignorant of?

xiaomai 5y ago

What are people using for a self-hosted "slack" type messenger these days? I have looked at Matrix (which I am interested in but I think needs time to settle right now), Zulip (I really like their threading model but it has been confusing for other people I have tried it with), Rocket chat (only recently aware of this one). What else is there? Anyone have good/bad experiences with any of these?

cyberlurker 5y ago
Mattermost is okay
- dbrgn 5y ago
  Yeah, I have good experiences with Mattermost (bundled with GitLab) as chat for a hackerspace/makerspace. As long as you're OK with unencrypted push messages, building your own version of the app and keeping it up to date is horrible. (React native levels of horrible.)
mxuribe 5y ago
> ...I think needs time to settle right now... I hear this on occasion (though more rarer nowadays than in the past)...But curious, is there something specific that you're finding in matrix that is not yet settled? By all means, the beauty of open source stuff is that you get to choose whether you (and your circle of contacts) uses zulip, mattermost, etc...So, i encourage you to use whatever open source offering gives you (and your circle of contacts) what is needed/desired. But with me being such a fanboy of matrix, i always get curious. Would you care to share specifics?
agentdrtran 5y ago
That's basically it. A lot of options but they all have some flaw. Rocket Chat and mattermost both lock features behind an enterprise paywall (although Rocket Chat is more forgiving and has optional E2EE), Zulip is nice but still a small player and some people aren't fans of the UX, and Matrix lacks the polish of slack and moderation tools are not up to speed with Slack/RC/Mattermost, which is a problem for larger groups.

remram 5y ago

> Matrix supports the concept of “key sharing”, letting a Matrix client which lacks the keys to decrypt a message request those keys from that user's other devices or the original sender's device. I'm a bit curious why you'd ever need to request those keys from somebody else, in addition to your own devices (or your homeserver, where they'd be stored encrypted by a key known by your own devices).

Youden 5y ago
Imagine you're a "normal" person who has a phone and doesn't really use a computer. You lose your phone and want to retrieve the history of a chat you had with your friend on the new phone. You ask your friend to send the key to your new device.
- remram 5y ago
  That sounds like a manual process that would not be part of the automated "key sharing" functionality as described.
Arathorn 5y ago
The recommendation is that devices only accept requests to share (forward) keys from a) other devices belonging to that user, b) the device which originally send the message. It's acceptable to gossip keys between your own devices (assuming you authenticate them correctly!) given... they're all your own devices. It's also acceptable to request the sender to re-send the keys to you, given the sender knows for sure whether you were allowed to receive the key (given it made that choice in the first place). It's not acceptable to request keys from other devices in the room, as they won't necessarily know whether you were actually allowed to receive the message key you're requesting - only the sender knows for sure whether it should have been sent to you; it was their key after all. Plus it would risk make vulnerabilities like the one in question here even worse, given anyone could try to exfiltrate messages from anyone else, rather than "just" the sender (as was the case here).

nightpool 5y ago

With the recent dust-up around protonmail's "end-to-end encryption", it's hard for me to believe that the hammer isn't going to come down on Matrix in a similar way. Nobody has seriously turned their attention to the compromised-homeserver issue, even though that's the only threat model under which e2ee makes sense. Expecting users in hundred-person group chats to manually verify each other individual user's keys is nonsensical. And even a single unverified key means that their homeserver operator could be listening in. I feel like Matrix should move more towards emphasizing how easy it is to self-host and maintain control of your own Matrix data, making e2ee is a non-issue.

COGlory 5y ago
What dustup around end-to-end encryption? I'm only familiar with ProtonMail's IP logging controversy. I was unaware it impacted E2E at all?
- deleted 5y ago
  [deleted]
- abnercoimbre 5y ago
  Did you find further information? Would've been nice for the GP to point to a source or news item.
- 0xdeadb00f 5y ago
  I'm pretty sure OP is just misinformed. That, or they're talking about that one huge hole in PM's PGP implementation years and years ago.
- nightpool 5y ago
  Right, the dust-up was "PM advertises their service as secure and end-to-end encrypted, but in practice that doesn't mean much because user access is non-anonymous and they're still a central metadata honeypot for any law enforcement agency to log accesses to" (compared to e.g. Signal which AIUI is designed as an anonymous dropbox so that Signal can't correlate between user access to their servers and individual senders)

m-p-3 5y ago

Still haven't received the up-to-date version from F-Droid, which is still stuck at 1.2.0. They really should have some provision to expedite a release when a serious security flaw is discovered. Not the Matrix team's fault, but still a bit worrying. Maybe they could implement their own F-Droid repo to skip the F-Droid build server?

progval 5y ago
Or they could coordinate with the F-Droid packagers, like they did for other distributions. (Actually they might have, since they don't exhaustively list them)
- callahad 5y ago
  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 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/76c8f5b87aa8dfc508b97805602c9496e2233a00 https://gitlab.com/fdroid/fdroiddata/-/commit/76c8f5b87aa8df... - SchildiChat 1.2.2.sc43: https://gitlab.com/fdroid/fdroiddata/-/commit/232b316f8affe0e538d0769c92fa3564b9c488e2 https://gitlab.com/fdroid/fdroiddata/-/commit/232b316f8affe0...
  - nybble41 5y ago
    > Because F-Droid runs their own builds and requires published source code, … That seems… completely reasonable for distributors of open-source projects. Mandatory, even, for compliance many open-source licenses. Are you saying there are other open source repositories (e.g. Linux distros) which would not require published source code before distributing binaries?
    - callahad 5y ago

deleted 5y ago

[deleted]

ncmncm 5y ago

In other news, Nheko supports E2EE.

Sami_Lehtinen 5y ago

Quote from the original documentation: "The recommended strategy is to share the keys automatically only to verified devices of the same user. Requests coming from unverified devices should prompt a dialog, allowing the user to verify the device, share the keys without verifying, or not to share them (and ignore future requests). A client should also check whether requests coming from devices of other users are legitimate." - It made me smile, because should and recommended doesn't generally mean anything to developers. Only mandatory, must and must not, sections might get some attention.

jeroenhd 5y ago

> As discussed above, key sharing was originally introduced to make E2EE more reliable while we were ironing out its many edge cases and failure modes. Based on what I understand about this feature, I've had to rely on key sharing quite often (even requiring manually requesting keys a bunch of times) for E2EE to work reliably. I worry that my experience will be severely degraded if key sharing ends up being removed from the protocol. Having the sending party re-encrypt messages for a new device require the other party to be online. I can see that requirement not being met in several ways, e.g. if the other party dies or uninstalls the application, or when the other end is arrested (I can imagine journalists losing access to activists' messages because of this).

Arathorn 5y ago
> I've had to rely on key sharing quite often (even requiring manually requesting keys a bunch of times) for E2EE to work reliably. This is because it's papering over edge cases in E2EE. > Having the sending party re-encrypt messages for a new device require the other party to be online We never make senders re-encrypt messages like this, and we never would. Firstly, key-sharing from the sender does require the other party to be online already. Otherwise, if you have the keys in an existing device, you could get them onto your new device by backing them up on the server - or using "dehydrated" devices; where the 'new' device you log into is actually one which is stored encrypted on the server, and "re-hydrated" into a new device when you login... and so already has your keys. These have security trade-offs obviously (what if your online backup gets pwned? what if your dehydrated device gets pwned?) but it's not obviously worse than exfiltrating the missing keys from the sender.