* Fix type issue around `getSessionBackupPrivateKey`
* Fix sending auth: null due to broken types around UIA
* Discard changes to src/crypto/index.ts
* Add comment
* Fix types
* Fix types for MatrixClient::addThreePid
* Iterate
* Fix type issue around `getSessionBackupPrivateKey`
* Fix sending auth: null due to broken types around UIA
* Discard changes to src/crypto/index.ts
* Add comment
* Simple request logging with status and duration
* remove url params from logs
* superfluous toString()
* Add tests
* Apply suggestions from code review
* update snapshots
* update log format
* Apply suggestions from code review
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* update snapshot
---------
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <richard@matrix.org>
* Offer `m.qr_code.scan.v1` verification method by default
Normally, the application specifies the supported verification methods when
creating the MatrixClient (and matrix-react-sdk does so). If the application
leaves it unset, then the idea is that the js-sdk offers all known verification
methods.
However, by default, the rust-sdk doesn't specify `m.qr_code.scan.v1`. So
basically, we need to set our own list of supported methods, rather than
relying on the rust-sdk's defaults.
* Factor out base class from `RustSASVerifier`
* Implement QR code scanning
* Update src/rust-crypto/verification.ts
* Use `cryptoBackend` in `client.ts` for new rust-crypto implementation for backward compatibility
* Use `cryptoBackend` in `client.ts` for new rust-crypto implementation for backward compatibility
* Simplify `MatrixClient::setPowerLevel` API
While making it more resilient to causing issues like nuking room state
* Handle edge case
* Fix tests
* Add test coverage
* use oidc-client-ts during oidc discovery
* export new type for auth config
* deprecate generateAuthorizationUrl in favour of generateOidcAuthorizationUrl
* testing util for oidc configurations
* test generateOidcAuthorizationUrl
* lint
* test discovery
* dont pass whole client wellknown to oidc validation funcs
* add nonce
* use oidc-client-ts for oidc response
* validate user state and update tests
* use oidc-client-ts for code exchange
* use oidc-client-ts in completing auth grant
* use client userState for homeserver
* more comments
* use oidc-client-ts during oidc discovery
* export new type for auth config
* deprecate generateAuthorizationUrl in favour of generateOidcAuthorizationUrl
* testing util for oidc configurations
* test generateOidcAuthorizationUrl
* lint
* test discovery
* dont pass whole client wellknown to oidc validation funcs
* add nonce
* use client userState for homeserver
* Fix an instance of failed to decrypt error
Specifically, when checking the event sender matches who sent us the
session keys we skip waiting for pending device list updates if we
already know who owns the session key.
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update src/crypto/algorithms/olm.ts
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Fix line wrapping
* Update src/crypto/algorithms/olm.ts
* Fix null check
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* implement `VerificationRequest.pending`
* Implement `VerificationRequest.timeout`
* Rust crypto: allow using a memory store (#3536)
* Rust crypto: allow using a memory store
It turns out that, for some usecases (in particular, "bot users" for cypress
tests), we don't need persistent storage and an in-memory store will be fine.
* Rust crypto: use a memory store for the unit tests
* Pass `supportedVerificationMethods` into `VerificationRequest`
... so that the application can later call `accept()` and we know what to send.
* Implement `VerificationRequest.accept`
* Implement `VerificationRequest.declining`
* Update src/rust-crypto/verification.ts
Currently, the anchor emoji has a ["Variation
Selector-16"](https://codepoints.net/U+FE0F) (U+FE0F) character after it.
The unicode specs do define U+2694 U+FE0F as a valid sequence (with suggested
rendering https://www.unicode.org/cgi-bin/varglyph?24-2693-FE0F), but our spec
spec doesn't include the variation selector, and the difference means that my
cypress tests (which attempt a verification between Element-R and unrusty
Element Web) fail intermittently.
Something of a follow-up to
https://github.com/matrix-org/matrix-js-sdk/pull/3523, but hopefully this will
be the last, because I have regenerated the whole list from the spec data.
* integ tests: factor out some utility methods
* Add `VerificationRequest.startVerification` to replace `beginKeyVerification`
The rust SDK ties together creating the verifier and sending the
`m.key.verification.start` message, so we need to combine
`.beginKeyVerification` and `.verify`.
* add some unit tests
