Force recovery key (4S) setup on first device when force_verification is set#33677
Open
FantasticoFox wants to merge 1 commit into
Open
Force recovery key (4S) setup on first device when force_verification is set#33677FantasticoFox wants to merge 1 commit into
FantasticoFox wants to merge 1 commit into
Conversation
… is set `force_verification` is meant to guarantee a recoverable encrypted identity, but it currently only gates on cross-signing readiness. On a first device the transparent InitialCryptoSetup sets up cross-signing without ever creating secret storage (4S), so `shouldForceVerification()` returns false and the user reaches the app with no recovery key; losing that device then strands their identity. Make the gate also require secret-storage readiness, and when a first device has cross-signing ready but no 4S, drive the existing recovery-key creation flow (`accessSecretStorage`) before login completes. The reset is gated on `secretStorage.hasKey()` (`forceReset: !hasExisting4S`) so a returning user whose 4S exists server-side but is not yet cached on this device is taken through the non-destructive unlock path instead of having their recovery key and key backup reset. Cross-signing is never regenerated. If the user cancels or the attempt fails, offer an explicit Retry / sign-out choice rather than silently leaving them stranded on the (now inert) setup screen, so the requirement can never be slipped past and the user can never be trapped with no way forward. No behavior change when `force_verification` is unset. Signed-off-by: Tim Bansemer <tim.bansemer@inblock.io>
github-actions
Bot
added
the
Z-Community-PR
|
|
Half-Shot
requested review from
a team and
andybalaam
and removed request for
a team
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
force_verificationis meant to guarantee a recoverable encrypted identity, but it currently only gates on cross-signing readiness. On a first device the transparent InitialCryptoSetup sets up cross-signing without ever creating secret storage (4S), soshouldForceVerification()returns false and the user reaches the app with no recovery key; losing that device then strands their identity.Make the gate also require secret-storage readiness, and when a first device has cross-signing ready but no 4S, drive the existing recovery-key creation flow (
accessSecretStorage) before login completes. The reset is gated onsecretStorage.hasKey()(forceReset: !hasExisting4S) so a returning user whose 4S exists server-side but is not yet cached on this device is taken through the non-destructive unlock path instead of having their recovery key and key backup reset. Cross-signing is never regenerated.If the user cancels or the attempt fails, offer an explicit Retry / sign-out choice rather than silently leaving them stranded on the (now inert) setup screen, so the requirement can never be slipped past and the user can never be trapped with no way forward.
No behavior change when
force_verificationis unset.Checklist
public/exportedsymbols have accurate TSDoc documentation.