* Support for showing QR codes
* Emit `VerificationRequestEvent.Change` events when the verifier changes
* Minor integ test tweaks
* Handle transitions from QR code display to SAS
* Fix naming
* Add a test for `ShowQrCodeCallbacks.cancel`
* 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
* 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
* 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
* More slow test fixes
* Create a new event type for verification requests
Previous PRs (https://github.com/matrix-org/matrix-js-sdk/pull/3449, etc) have
pulled out an interface from the `VerificationRequest` class, but applications
registering for the `CryptoEvent.VerificationRequest` event could still be
expecting a fully-fledged class rather than the interface.
To handle this without breaking backwards compat, add a new event type that
carries the interface, not the class.
* Element-R: Implement `CryptoApi.getVerificationRequestsToDeviceInProgress`
* Element-R: Implement `requestOwnUserVerification`
* init aliceClient *after* the fetch interceptors
* Initialise the test client separately for each test
* Avoid running all the tests twice
Currently all of these tests are running twice, with different client
configurations. That's not really adding much value; we just need to run
specific tests that way.
* Factor out functions for building responses
* Return uploaded keys from `/keys/query`
* Basic implementation of SAS verification in Rust
* Update the `verifier` *before* emitting `erificationRequestEvent.Change`
* remove dead code
* Tweaks to the integ test to conform to the spec
Rust is a bit more insistent than legacy crypto...
* Improve documentation on request*Verification
* Check more things in the integration test
* Create an E2EKeyResponder
* Test verification with custom method list
* Add a test for SAS cancellation
* Update spec/integ/crypto/verification.spec.ts
* Store cross signing keys in secret storage
* Update `bootstrapSecretStorage` doc
* Throw error when `createSecretStorageKey` is not set
* Move mocking functions
* Store cross signing keys and user signing keys
* Fix `awaitCrossSigningKeyUpload` documentation
* Remove useless comment
* Fix formatting after merge conflict
* add a test for incoming verification requests
* Move `VerificationRequestEvent` to crypto-api
* Move `VerificationPhase` to `crypto-api`
* Define `VerificationRequest` interface
* Implement `canAcceptVerificationRequest`
* Add `crypto.getCrossSigningStatus`
* Fix imports and boolean casting
* Moved `isStoredInSecretStorage` into a single function
* Review changes `CrossSigningStatus`
* Review changes for `cross-signing.spec.ts`
* Add test in case when cross signing is not setup
* Handle when the `crossSigningStatus` returned by the olmMachine is null
* Review changes for `crypto-api` documentation
* Update `cross-signing.spec.ts` according to review changes
* Moved and renamed `isStoredInSecretStorage`
* Remove noise in `CrossSigning.ts` imports
* Fix `returns` sentence in `secretStorageContainsCrossSigningKeys`
* Fix typos
* Add test for `secret-storage.ts`
* Improve documentation
* Add doc about fetch mock request name
* Add new method `VerificationRequest.getQRCodeBytes`
... which requires fewer complicated classes than the existing `qrCodeData`
* Add new property `VerificationRequest.otherDeviceId`
... to save going via `.channel`
* Add more methods to `VerificationRequest`
... to avoid the need for `channel`
* Use new methods in integration tests
* Add `getShowSasCallbacks`, `getShowQrCodeCallbacks` to VerifierBase
... to avoid some type-casting
* Integration test for QR code verification
Followup to https://github.com/matrix-org/matrix-js-sdk/pull/3436: another
integration test, this time using the QR code flow
* Rename method
... it turns out not to be used quite as I thought.
* tests for new methods
* Use Object.defineProperty, and restore afterwards
Apparently global.crypto exists in some environments
* apply ts-ignore
* More test coverage
* fix bad merge
* Integration test for QR code verification
Followup to https://github.com/matrix-org/matrix-js-sdk/pull/3436: another
integration test, this time using the QR code flow
* Use Object.defineProperty, and restore afterwards
Apparently global.crypto exists in some environments
* apply ts-ignore
* remove stray comment
* Update spec/integ/crypto/verification.spec.ts
* Move existing crypto integ tests into a subdirectory
* Factor out some common bits from `crypto.spec.ts`
* Integration test for device verification
* Ignore generated file in prettier
