Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…ation (#3472)

* Add `rust-crypto#createRecoveryKeyFromPassphrase` implementation

* Use `crypto`

* Rename `IRecoveryKey` into `GeneratedSecretStorageKey` for rust crypto

* Improve comments

* Improve `createRecoveryKeyFromPassphrase`

#3449 deprecated a bunch of
exports from `src/crypto/verification/request/VerificationRequest`. Let's stop
using them in the integration test.

…close errors (#3478)

* Add accessors for verification requests to CryptoApi

Part of element-hq/crypto-internal#97

* Add new methods for verification to `CryptoApi` and deprecate old method

element-hq/crypto-internal#98

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…enovate PRs (#3480)

* `CryptoApi` should be first
* `export *` should be last
* everything else in the middle

* Add WIP bootstrapSecretStorage

* Add new test if `createSecretStorageKey` is not set

* Remove old comments

* Add docs for `crypto-api.bootstrapSecretStorage`

* Remove default parameter for `createSecretStorageKey`

* Move `bootstrapSecretStorage` next to `isSecretStorageReady`

* Deprecate `bootstrapSecretStorage` in `MatrixClient`

* Update documentations

* Raise error if missing `keyInfo`

* Update behavior around `setupNewSecretStorage`

* Move `ICreateSecretStorageOpts` to `rust-crypto`

* Move `ICryptoCallbacks` to `rust-crypto`

* Update `bootstrapSecretStorage` documentation

* Add partial `CryptoCallbacks` documentation

* Fix typo

* Review changes

* Review changes

* Element-R: wait for OlmMachine on startup

Previously, if you called `CryptoApi.getUserDeviceInfo()` before the first
`/sync` request happened, it would return an empty list, which made a bunch of
the tests racy. Add a hack to get the OlmMachine to think about its device
lists during startup.

* add a test

#3489)

…3494)

* Fix debug logging not working

* Add debug logging to figure out missing reactions in main timeline

…nderlying Room (#3493)

* rename OidcDiscoveryError to OidcError

* oidc client registration functions

* test registerOidcClient

* tidy test file

* reexport OidcDiscoveryError for backwards compatibility

A couple of tests were waiting for a request that wasn't happening, so timing
out after 1.5 seconds. Let's avoid the extra slowth.

(This was introduced by changes in
#3487, but the changes in this
PR do no harm anyway)

For some reason, some tests seem to be timing out in GHA. Let's try bumping up
the timeout.

* 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

* 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

#3496)

* Return uploaded keys from `/keys/query`

* Basic implementation of SAS verification in Rust

* Update the `verifier` *before* emitting `erificationRequestEvent.Change`

* remove dead code

`cypress.yaml` is currently pinned to an old version of the react-sdk, meaning
that each attempt to run it is currently failing with an error.

(Introduced by #3480)

…ress` (#3497)

* Element-R: Implement `CryptoApi.getVerificationRequestsToDeviceInProgress`

* Element-R: Implement `requestOwnUserVerification` (#3503)

* Revert "Element-R: Implement `requestOwnUserVerification` (#3503)"

This reverts commit 8da7565.

oops, merged too soon

Part of element-hq/element-web#25319.

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* 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

We still seem to be suffering test timeouts. Hopefully this will fix the integ tests, where #3509 etc fix the unit tests.

* utils for authorization step in OIDC code grant

* tidy

* completeAuthorizationCodeGrant util functions

* response_mode=query

* add scope to bearertoken type

* add is_guest to whoami response type

* doc comments

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* use shimmed TextEncoder

* fetchMockJest -> fetchMock

* comment

* bearertokenresponse

* test for lowercase bearer

* handle lowercase token_type

---------

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

Followup to #3500: increase the
timeout for another test which is also timing out.

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* More slow test fixes

* Create a new event type for verification requests

Previous PRs (#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.

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

[`crypto.getRandomValues`](https://nodejs.org/docs/latest-v18.x/api/crypto.html#cryptogetrandomvaluestypedarray)
was added to the nodejs library in node 17. However, it was actually available
in node 16, hiding under
[`crypto.webcrypto`](https://nodejs.org/docs/latest-v16.x/api/webcrypto.html#cryptogetrandomvaluestypedarray). We
have some shims in `src/crypto/crypto.ts`, so let's use them.

All of this means that we don't need to monkey-patch `crypto` to run the tests
on node 16.

* 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

* Stop running tests on Node 16

* update package.json

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
#3523, but hopefully this will
be the last, because I have regenerated the whole list from the spec data.

* 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

* 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

* validate id token

* comments

* tidy comments

…uery` fails. (#3486)

* 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>

…3540)

* Ignore thread relations on state events for consistency with edits

* Add test

…3537)

... to help with debugging.

* don't allow Olm unwedging rate-limiting to race

* apply changes from code review

Signed-off-by: Timo K <toger5@hotmail.de>

* 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

Bumps [tough-cookie](https://github.com/salesforce/tough-cookie) from 4.1.2 to 4.1.3.
- [Release notes](https://github.com/salesforce/tough-cookie/releases)
- [Changelog](https://github.com/salesforce/tough-cookie/blob/master/CHANGELOG.md)
- [Commits](salesforce/tough-cookie@v4.1.2...v4.1.3)

---
updated-dependencies:
- dependency-name: tough-cookie
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

The api to generate a QR code is async in rust, and the easiest way to deal
with it is to make a new method.

Signed-off-by: Timo K <toger5@hotmail.de>