This is a meta issue for the two issues I found while investigating rage shakes earlier this week, present in both the Rust SDK and the JS SDK, and hence affects all of our software.
Recovery::reset_identity (Rust SDK) and RustCrypto.resetEncryption run their destructive steps against the local store (delete backup, disable secret storage, and generate a new private cross-signing identity) before UIA-gated fallible upload step. If the user never completes this, the server keeps the old identity while the local store holds a new one.
The next /keys/query response that includes our own user then removes every local private cross-signing key via PrivateCrossSigningIdentity::clear_if_differs (Rust SDK) while the device remains cross-signed by the old identity. This is particularly bad on EX platforms, since if the device was verified, the Rust SDK continues to report VerificationState::Verified since verification is performed using the public half of the old self-signing key, which the broken client still holds.
This is a meta issue for the two issues I found while investigating rage shakes earlier this week, present in both the Rust SDK and the JS SDK, and hence affects all of our software.
Recovery::reset_identity(Rust SDK) andRustCrypto.resetEncryptionrun their destructive steps against the local store (delete backup, disable secret storage, and generate a new private cross-signing identity) before UIA-gated fallible upload step. If the user never completes this, the server keeps the old identity while the local store holds a new one.The next
/keys/queryresponse that includes our own user then removes every local private cross-signing key viaPrivateCrossSigningIdentity::clear_if_differs(Rust SDK) while the device remains cross-signed by the old identity. This is particularly bad on EX platforms, since if the device was verified, the Rust SDK continues to reportVerificationState::Verifiedsince verification is performed using the public half of the old self-signing key, which the broken client still holds.