fix: stop refusing private-key writes on a config-mode guess - #239
Open
bmatusiak wants to merge 2 commits into
Open
fix: stop refusing private-key writes on a config-mode guess#239bmatusiak wants to merge 2 commits into
bmatusiak wants to merge 2 commits into
Conversation
Advanced refused to send when the store's isConfigMode read false, showing "Put your OnlyKey in config mode (flashing red LED)" to users whose key was in config mode with the LED flashing. The flag is an inference - the firmware reports the same UNLOCKED status either way - and it reads false whenever the app missed the one transition that sets it, such as starting up with the key already in config mode. There was no way to recover from inside the app. The legacy app carries the same flag but never gated a write on it, so this was a regression introduced by the rewrite. Removing the gate restores that behaviour: send, and let the device answer. Its refusal already routes through the existing catch blocks, and formatDeviceLockedError turns "Error not in config mode" into the instructions - so nothing there needs changing now that the firmware names the right reason. Measured end to end against the emulator: in config mode the wipe reports "Private key wiped from slot 101", and outside it the user gets the config-mode instructions rather than "unlock your device". The protocol side is pinned by onlykey-testing 01-protocol/27-config-mode-observability. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
wipe key bug
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.
Advanced refused to send when the store's isConfigMode read false, showing "Put your OnlyKey in config mode (flashing red LED)" to users whose key was in config mode with the LED flashing. The flag is an inference - the firmware reports the same UNLOCKED status either way - and it reads false whenever the app missed the one transition that sets it, such as starting up with the key already in config mode. There was no way to recover from inside the app.
The legacy app carries the same flag but never gated a write on it, so this was a regression introduced by the rewrite. Removing the gate restores that behaviour: send, and let the device answer. Its refusal already routes through the existing catch blocks, and formatDeviceLockedError turns "Error not in config mode" into the instructions - so nothing there needs changing now that the firmware names the right reason.
Measured end to end against the emulator: in config mode the wipe reports "Private key wiped from slot 101", and outside it the user gets the config-mode instructions rather than "unlock your device". The protocol side is pinned by onlykey-testing
01-protocol/27-config-mode-observability.