* Add `getUserDeviceInfo` to `CryptoBackend` and old crypto impl
* Add `getUserDeviceInfo` WIP impl to `rust-crypto`
* Add tests for `downloadUncached`
* WIP test
* Fix typo and use `downloadDeviceToJsDevice`
* Add `getUserDeviceInfo` to `client.ts`
* Use new `Device` class instead of `IDevice`
* Add tests for `device-convertor`
* Add method description for `isInRustUserIds` in `rust-crypto.ts`
* Misc
* Fix typo
* Fix `rustDeviceToJsDevice`
* Fix comments and new one
* Review of `device.ts`
* Remove `getUserDeviceInfo` from `client.ts`
* Review of `getUserDeviceInfo` in `rust-crypto.ts`
* Fix typo in `index.ts`
* Review `device-converter.ts`
* Add documentation to `getUserDeviceInfo` in `crypto-api.ts`
* Last changes in comments
* minor cleanups to the crypto tests
mostly, this is about using `testUtils.awaitDecryption` rather than custom
code. Some other cleanups too.
* Keep a record of events which are missing their keys
* Retry event decryption when we receive megolm keys
* Send one time key count and unused fallback keys for rust-crypto
* Add tests
* Remove useless type in promise return
* Add test for one time key upload
* Fix rust-crypto.spec.ts tests
* Remove unneeded code in test
* Add key upload request test
* Fix tests
* crypto.spec.ts: factor out `expactAliceKeyClaim` utility
* Add a new test for event encryption
... one that actually works on the rust SDK.
* Bump matrix-sdk-crypto-js version
... to pick up recent fixes to race conditions
* Associate event with thread before adding it to the thread timeline
* Make sure events can be added to thread correctly
* Write initial test case
* Add additional comment for why the code had to be reordered
I became sufficiently annoyed with matrix-mock-request that I decided to replace it with fetch-mock, which is what we use in matrix-react-sdk and is generally more powerful, easier to use, and actually maintained.
Unfortunately, we have a TestClient utility which is widely used and quite tightly integrated with matrix-mock-request. It wasn't going to be possible to change TestClient without changing all the tests that use it.
I also don't find TestClient particularly easy to use - it does a lot of stuff which I'm not convinced ought to be done for every single test.
So... I've introduced a couple of new classes (SyncResponder, E2EKeyReceiver) which do some of the useful bits of TestClient, but in a more granular way, and have switched crypto.spec.ts over so that rather than instantiating a TestClient for each test, it creates a MatrixClient directly and intercepts the endpoints necessary.
* refactor: sliding sync: swap to lists-as-keys
Update the request/response API shape to match the latest
MSC3575 version, which converts `lists` from being an array
of list objects to being a map of list objects.
* Linting
* prettier
* add extra setListRanges test
* Default to right type
* refactor: sliding sync: swap to lists-as-keys
Update the request/response API shape to match the latest
MSC3575 version, which converts `lists` from being an array
of list objects to being a map of list objects.
* Linting
* prettier
* add extra setListRanges test
* Default to right type
* `matrix-client-crypto.spec.ts` only tested a very specific bit of crypto (olm
encryption). It goes back to the very early days, before Megolm was invented.
I've renamed it to `olm-encryption-spec.ts`.
* `megolm-integ.spec.ts` is more of a general crypto test; it was just called
`megolm` to distinguish it from the Olm tests above. Renamed to
`crypto.spec.ts`.
This test seemed to be testing the behaviour of decrypting redacted events, but
that seems... strange. A redaction event cannot be encrypted (at least, there
is no spec for it), and it should be impossible to decrypt a (correctly)
redacted event, because such an event will lack a `ciphertext` property.
This test is just sticking a "redacted_because" property into a regular event,
which is a bit of a nonsense.
The megolm tests were making a few assumptions which they really shouldn't; in
particular:
* They were creating mock events with event_ids not starting `$`, and lacking
`sender`, `origin_server_ts` and `unsigned` properties
* They were not including the (now) required `keys.ed25519` property inside
the ciphertext of an olm message.
These work ok currently, but they aren't really correct, and they cause
problems when testing the new rust implementation.
* Remove extensible events v1 field population on legacy events
With extensible events v2, affected events are now gated by a room version, so we don't need this code anymore.
The proposal has generally moved away from mixing m.room.message with extensible fields as well.
* Run prettier
* Remove unstable identifier from tests too
* Run prettier again
I need to start calling back into the new rust crypto implementation from the /sync loops, so I need to pass it into SyncApi. To reduce the coupling, I've defined a new interface specifying the methods which exist for that purpose. Currently it's only onSyncCompleted.
There are a couple of callback interfaces which are currently stuffed into
`IStoredClientOpts` to make it easier to pass them into the `SyncApi`
constructor.
Before we add more fields to this, let's separate it out to a separate object.
`Room` and `Crypto` currently have some tight coupling in the form of a call to
`trackRoomDevices` when out-of-band members are loaded. We can improve this by
instead having Crypto listen out for a `RoomSateEvent.Update` notification.
This PR introduces MatrixClient.initRustCrypto, which is similar to initCrypto, except that it will use the Rust crypto SDK instead of the old libolm-based implementation.
This is very much not something you want to use in production code right now, because the integration with the rust sdk is extremely skeletal and almost everything crypto-related will raise an exception rather than doing anything useful.
It is, however, enough to demonstrate the loading of the wasmified rust sdk in element web, and a react sdk with light modifications can successfully log in and out.
Part of vector-im/element-web#21972.
Part of https://github.com/vector-im/element-web/issues/21972. Eventually I want to replace the whole of the current `Crypto` implementation with an alternative implementation, but in order to get from here to there, I'm factoring out a common interface which will be implemented by both implementations.
I'm also determined to fix the problem where the innards of the crypto implementation are exposed to applications via the `MatrixClient.crypto` property.
It's not (yet) entirely clear what shape this interface should be, so I'm going with a minimal approach and adding things as we know we need them. This means that we need to keep the old `client.crypto` property around as well as a new `client.cryptoBackend` property. Eventually `client.crypto` will go away, but that will be a breaking change in the js-sdk.
* Fix issue where the root event of a thread had to be loaded in a complicated way
* Fix issue where edits to the last event of a thread would get lost
* Fix issue where thread reply count would desync
* Refactor relations pagination mocking for tests
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.
