Repository navigation
fix(device-client): harden the reveal, request paths and ended approvals - #134
Merged
Merged
Conversation
…rovals A network failure during the reveal is retried (bounded) and never cancels the approval; only a real mismatch does. ApproverState's Debug hides the digits and the fingerprint. Ids in request paths are percent-encoded. confirm and deny on an ended approval give ApprovalExpired and never approve. The approver can read the time left from the expiry the server already returns.
A reveal whose answer was lost, followed by a failed read, left the approver stuck: every later send got 409 and the digits never showed. The server is now asked whether it holds the nonce before a kept reveal is sent again and after a 409, and held counts as sent.
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
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.
Summary
approval_stateno longer cancels the approval: the reveal is sent up to 3 times, asking the server first whether it already holds it (lost answer); a failure that outlasts the tries isTransportand the same approval goes on. The engine's reveal is kept until the server has it. Only a real mismatch cancels.ApproverState::Digitshas a manualDebug(Digits { .. }): digits and fingerprint never print.approvals.rs;sync.rsalready did;client.rshas none):a/b?cbecomesa%2Fb%3Fc.deny_approvalreads the approval first, so an ended one (expired, answered, used, cancelled) isApprovalExpiredwith no second cancel sent;confirm_approvalalready gets the server's 410. Nothing is approved.DeviceClient::time_left(&approval): the server already returnsexpires_at(RFC 3339, UTC) inApprovalCreatedandPendingApproval; minus this device's clock; zero once passed,Noneif unreadable. No server change.Testing
tests/approvals.rs), unit tests for paths and times, and a real-server test for confirm/deny after the new device cancelled.Co-authors
none
AI usage
Checklist
docs/architecture.mdwith any rule change; generated wire types with any contract change