[E2E] Device verification #263
Closed
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
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.
Since device tracking is done in a separate thread, we need to be careful not to use the same connection object between threads (in fact the problem existed since the first persistence commit when using MatrixClient.start_listener_thread).
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Penultimate missing feature.
This was unexpectedly complicated to implement, as it required small changes everywhere and as the logic behind the few checks that get added is not trivial.
Some notes about the design:
- Since the SDK is mainly used by bots, device verification is disabled by default (enabling it is as painless as passing
verify_devices=Truewhen instantiatingMatrixClient, though).- Unlike in the JS SDK, there is no
Eventclass. This means that one cannot use something likeevent.isVerified()after getting an event from the SDK in order to know if they should treat an event as trusted.It could be tempting to infer that an event is trusted from the fact that it is sent in an encrypted room and that it comes from a verified device. However this would be broken because, as the decryption of events is transparent, an event received in a encrypted room could very well be unencrypted, thus not trusted.
There are a lot of possible tricks to work around this limitation. The less hacky one felt like adding a
VerifiedEventdict subclass. In order to check if an event is verified, one has to import it frommatrix_client.crypto.verified_event, and add the checkif isinstance(event, VerifiedEvent): .... Not perfect, but at least readable.In order to verify or blacklist a device, it is possible to do one of the following:
- From a
Userobject, use thedevicesproperty to get a map from device ID toDeviceobject. Then, display theed25519property (the fingerprint) of a device, and turn on theblacklistedorverifiedproperty accordingly.- When sending a message in an encrypted room where device verification in enabled, the exception
E2EUnknownDevicesdefined inerrors.pywill be raised if there are new unknown devices. One can inspect theuser_devicesproperty of this exception, and will find a map from user ID to a list ofDeviceobjects. For each of those device, one of the previous properties should be set in order to be able to successfully send the message. Note that there is also anignoredproperty of aDeviceobject that can be turned on, in order to send a message anyway to unverified devices.Currently, it is impossible to verify the devices of a user if we do not share an encrypted room with them.
Signed-off-by: Valentin Deniaud <valentin.deniaud@inpt.fr>