* Update src with globalThis
* Update spec with globalThis
* Replace in more spec/ places
* More changes to src/
* Add a linter rule for global
* Prettify
* lint
* Add CryptoApi. encryptToDeviceMessages
Deprecate Crypto. encryptAndSendToDevices and MatrixClient. encryptAndSendToDevices
* Overload MatrixClient. encryptAndSendToDevices instead of deprecating
* Revert "Overload MatrixClient. encryptAndSendToDevices instead of deprecating"
This reverts commit 6a0d8e2638.
* Feedback from code review
* Use temporary pre-release build of @matrix-org/matrix-sdk-crypto-wasm
* Deduplicate user IDs
* Test for RustCrypto implementation
* Use ensureSessionsForUsers()
* Encrypt to-device messages in parallel
* Use release version of matrix-sdk-crypto-wasm
* Upgrade matrix-sdk-crypto-wasm to v8
* Sync with develop
* Add test for olmlib CryptoApi
* Fix link
* Feedback from review
* Move libolm implementation to better place in file
* FIx doc
* Integration test
* Make sure test device is known to client
* Feedback from review
* Introduce Membership TS type
* Adapt the Membership TS type to be an enum
* Add docstrings for KnownMembership and Membership
* Move Membership types into a separate file, exported from types.ts
---------
Co-authored-by: Stanislav Demydiuk <s.demydiuk@gmail.com>
* Comment explaining the purpose of RoomList
* Fix incorrect return type declaration on RoomList.getRoomEncryption
* Move RoomList out of MatrixClient, into legacy Crypto
* Initialise RoomList inside Crypto.init to allow us to await it
* Add current version of the rust-sdk and vodozemac
* Return OlmVersion in `CryptoApi#getVersion` for old crypto
* Add `Olm` prefix
* Fix documentation
* Review changes
* rename loglevel import to loglevel
* Define new `Logger` interface to replace `PrefixedLogger`
* PrefixedLogger -> Logger in crypto store
* PrefixedLogger -> Logger in `src/crypto`
* PrefixedLogger -> Logger in rust-crypto
* Refactor the room key handling method
* Fix the forwarded room key test to use the same user ids.
We have some tests that check if receiving a forwarded room key works.
These claim to use the same user id, but in fact they change the user id
in the last moment before the event is passed into the client.
Let's change this so we're always operating with the same user id.
* Stop requesting room keys from other users
We never accept such room keys, so there isn't a point in requesting
them.
* fixup! Refactor the room key handling method
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* fixup! Refactor the room key handling method
* fixup! Apply suggestions from code review
* fixup! Refactor the room key handling method
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Rather than waiting for the application to call `.startClient`, upload the
device keys during `initCrypto()`. Element-R is going to approach this slightly
differently (it wants to manage the decision on key uploads itself), so this
lays some groundwork by collecting the libolm-specific bits together.
To make it easier to track down where to-device messages are getting lost,
add a custom property to each one, and log its value. Synapse will also log
this property.
vector-im/element-web#23819 is an intermittent failure to correctly initiate a user verification process. The
root cause is as follows:
* In matrix-react-sdk, ensureDMExists tries to create an encrypted DM room, and assumes it is ready for use
(including sending encrypted events) as soon as it receives a RoomStateEvent.NewMember notification
indicating that the other user has been invited or joined.
* However, in sync.ts, we process the membership events in a /sync response (including emitting
RoomStateEvent.NewMember notifications), which is long before we process any m.room.encryption event.
* The upshot is that we can end up trying to send an encrypted event in the new room before processing
the m.room.encryption event, which causes the crypto layer to blow up with an error of "Room was
previously configured to use encryption, but is no longer".
Strictly speaking, ensureDMExists probably ought to be listening for ClientEvent.Room as well as RoomStateEvent.NewMember; but that doesn't help us, because ClientEvent.Room is also emitted
before we process the crypto event.
So, we need to process the crypto event before we start emitting these other events; but a corollary of that
is that we need to do so before we store the new room in the client's store. That makes things tricky, because
currently the crypto layer expects the room to have been stored in the client first.
So... we have to rearrange everything to pass the newly-created Room object into the crypto layer, rather than
just the room id, so that it doesn't need to rely on getting the Room from the client's store.
* Add support for sending user-defined encrypted to-device messages
This is a port of the same change from the robertlong/group-call branch.
* Fix tests
* Expose the method in MatrixClient
* Fix a code smell
* Fix types
* Test the MatrixClient method
* Fix some types in Crypto test suite
* Test the Crypto method
* Fix tests
* Upgrade matrix-mock-request
* Move useRealTimers to afterEach
