matrix-org / matrix-org/matrix-rust-sdk
Handle failures when publishing cross-signing identity
- Dominant language
- Rust
- Stars
- 2.3k
- Forks
- 500
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 106
Description
Rust equivalent of https://github.com/element-hq/element-meta/issues/2410
We don't currently retry to upload the cross-signing if it fails.
This create a scenario where the current client thinks it is verified, and using cross-signing but this identity was not actually published to the homeserver.
So any other user will see the device as not verified.
There should be some mechanism to retry until the identity is uploaded, but this call can require re-authentication in some cases. Hence the reason why it was not done initially.
---
as per discussion:
> Is there a reason that the Crypto SDK's Swift Request enum doesn't include a .signingKeysUpload? Skimming through some of the Rust code, e.g. [mark_request_as_sent](https://github.com/matrix-org/matrix-rust-sdk/blob/331ea35be6278351f3179b5e287353aa53845df6/crates/matrix-sdk-crypto/src/machine.rs#L388), it seems like this should maybe be one of the possibilities.
> Otherwise I'm not sure how to mark my cross-signing identity as shared
The shared flag on the private part of the user identity isn't as useful since we can't automatically try to upload due to user interactive auth requirements, i guess the bad part is that we don't expose this shared flag so people can't know that the upload failed
Contributor guide
Research direction
Start in crates/matrix-sdk-crypto/src/machine.rs around mark_request_as_sent and review the linked cross-signing upload discussion. Trace how failed identity uploads and user-interactive authentication are represented, including the shared flag, then identify tests covering cross-signing publication. Done means the client can account for an upload failure and retry or expose its state without bypassing required re-authentication.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cryptography, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100