hive-matrix-mcp: never enable recovery over secret storage it did not create
`recovery().enable()` refuses only when a key backup exists. It then makes a new secret-storage key and sets it as the account's default regardless of the default already there, so an account with secret storage but no backup (set up in another client, backup since deleted) would have its default key replaced and its other clients' recovery key locked out. `recover_or_enable` now asks `secret_storage().is_enabled()` before `enable` and returns an error instead, which `ensure_recovery` logs at WARN with the account and the passphrase's store path. The decision is behind a small trait over the matrix-sdk calls so a fake can pin it: with no backup and secret storage present, neither `enable` nor `recover` runs. Review: argus on #5188.
This commit is contained in:
parent
45568f6e60
commit
aece1c26d0
2 changed files with 186 additions and 27 deletions
|
|
@ -318,8 +318,9 @@ Initial rollout settings:
|
|||
store, and never replaces it. When `hive-matrix-daemon` brings an
|
||||
account up it reads that passphrase: with no backup on the account's
|
||||
homeserver it turns on server-side key backup and secret storage
|
||||
(log line `matrix recovery enabled`); with one there it recovers from
|
||||
it (`recovered from the server-side key backup`), which downloads the
|
||||
(log line `matrix recovery enabled`), unless the account already has
|
||||
secret storage, which it never replaces (a `WARN` instead). With a
|
||||
backup there it recovers from it (`recovered from the server-side key backup`), which downloads the
|
||||
room keys and signs the new device with the account's existing
|
||||
cross-signing identity. A crypto store lost to `--purge` or to a
|
||||
primary-token reset therefore comes back with its history. With no passphrase
|
||||
|
|
|
|||
Loading…
Reference in a new issue