test(I6): disabling AdvancedMode must revoke the signer, not suspend it - #46
Merged
Conversation
I6 previously MEASURED and documented a gap instead of closing it: turning
AdvancedMode off left the loaded provider in RAM, and the test's own docstring
said so --
a user who disables AdvancedMode to revoke a provider has not revoked it,
only suspended it. Re-enabling the policy costs one button press whose
screen names the policy and never names the signer it silently re-arms.
That also contradicted docs/security/clearsign-provider-tier.md, which lists
"disabling AdvancedMode" among the events that clear identities. One of the two
had to move, and the doc was right: 7.15 is safe without any key-management
programme precisely because trust dies on its own, and a revocation that only
suspends is not one.
The firmware side is four lines in fsm_msgApplyPolicies (firmware PR). This
flips the assertion to match: after the policy round-trip the signer must be
GONE, and the bare-message expected-response list (one ButtonRequest, one
Success) proves trust cannot be restored by a policy toggle at all -- coming
back costs a fresh LoadClearsignSigner consent, which is the screen that names
the alias and fingerprint.
Renamed to say what it now asserts. The atlas entry follows.
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
1 participant
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.
I6 previously measured and documented a gap instead of closing it. Its own docstring:
That also contradicted
docs/security/clearsign-provider-tier.md, which lists disabling AdvancedMode among the events that clear identities. One of the two had to move, and the doc was right: 7.15 is safe without any key-management programme precisely because trust dies on its own, and a revocation that only suspends is not one.The firmware side is four lines in
fsm_msgApplyPolicies(firmware PR, pinned together with this). This flips the assertion: after the policy round-trip the signer must be gone, and the bare-message expected-response list — one ButtonRequest, one Success — proves trust cannot be restored by a policy toggle at all. Coming back costs a freshLoadClearsignSignerconsent, the screen that names the alias and fingerprint.Renamed to say what it now asserts; the atlas entry follows.