[E2E] Key sharing #268
Closed
[E2E] Key sharing #268
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
N.B. that if you ask the others in the room, their clients would have to track the membership of the room as of an arbitrary event (or megolm session) to try to decide whether the requester is even allowed to see that history from their perspective. I don't know of any client which does this yet. So it's probably best to just query your other devices rather than the other members. |
Contributor
Author
|
Sure, the point of what I wrote was that I had kept my hands off this, and that this better be spec'd before anyone attempts to implement it :) |
Use a thread to allow downloading the keys in a non-blocking way. Implement sort of a queue of users who need updating, which should be efficient (request is fired as soon as possible with as much data as possible) and avoid races (we always have only one download in progress).
This has the effect of tracking the device lists of users proactively.
Nicer sqlite practices and better docstrings.
A side-effect is that this removes the ability to store E2E data for different devices of the same user in the DB. It shouldn't be much of a problem as it is easy to use multiple DB files for different instances of MatrixClient. Signed-off-by: Valentin Deniaud <valentin.deniaud@inpt.fr>
Make those tests more maintanable by getting rid of unwanted side effects and useless cleanups by using pytest.fixture, along with some readability improvements.
Encryption shouldn't be supported on limited cache_level. Even if it may work a bit, it causes a lot of data to be cached.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Last big missing feature.
The functionality is pretty basic for now, in order to prevent a careless user to mess up and share every keys they can. As is, a user will only be prompted for key sharing if the request comes from another of their device.
Consequently, the requests are also sent only to the user's own devices, even though we could have been more broad since we have nothing to lose asking more devices (namely the sender's, and maybe all the others in the room).
This should be easy to change at a later time, especially when all this is better spec'd and more of the E2E code is reviewed.
There are two main user interactions: deciding to share keys or not when a request arrive, and being notified when a requested key arrives, in order to try to decrypt messages again. Hence, the user has to keep track of undecryptable messages to make the most of this. Maybe something more convenient could be implemented, but I don't have a satisfying idea for now.
Lastly, note that the performance of key sharing is bad, as there is no way to aggregate requests and forwards. If there is a spec change to allow this, implementing it would be very useful.
Signed-off-by: Valentin Deniaud <valentin.deniaud@inpt.fr>