Each control that leads to a signature or to the private key now has a unit test in tests/walletDefects.test.js that it refuses a defective wallet before decrypting anything: Send on the main, address and token screens, Export Private Key, and both approval screens, each checked as drawn (error shown, Approve disabled) and as clicked (no decrypt, nothing sent to the background).
Confirmation screen. Its Send is now gated the same way, with a test. The Send buttons stand in front of it, but confirm-tx is a view the popup reopens onto from saved state, so they are not the only way onto it.
Comments. The walletDefects.js module comment names both earlier import paths and says which one the depth check misjudges (7a7f9c5, in no tag). The export comment in addressDetail.js no longer says there is no key: it derives, and getSignerForAddress refuses it.
Worth knowing:
Each gate was deleted one at a time (the approval screens' gate at both call sites and both click guards separately, plus the new one), and every deletion failed its test.
The click-guard tests run a listener the screen has disabled, which a browser would not: they ask whether the handler refuses on its own.
The confirmation test makes the decrypt fail, because drawing that screen starts a network fee estimate.
Disclosures:
Judgement call: the same "cannot be derived" claim in two neighbouring comments (selectedWalletDefect in addressDetail.js, gateOnWalletDefect in approval.js) is corrected too.
Closes https://git.eeqj.de/sneak/AutistMask/issues/254.
Each control that leads to a signature or to the private key now has a unit test in `tests/walletDefects.test.js` that it refuses a defective wallet before decrypting anything: Send on the main, address and token screens, Export Private Key, and both approval screens, each checked as drawn (error shown, Approve disabled) and as clicked (no decrypt, nothing sent to the background).
**Confirmation screen.** Its Send is now gated the same way, with a test. The Send buttons stand in front of it, but `confirm-tx` is a view the popup reopens onto from saved state, so they are not the only way onto it.
**Comments.** The `walletDefects.js` module comment names both earlier import paths and says which one the depth check misjudges (`7a7f9c5`, in no tag). The export comment in `addressDetail.js` no longer says there is no key: it derives, and `getSignerForAddress` refuses it.
Worth knowing:
- Each gate was deleted one at a time (the approval screens' gate at both call sites and both click guards separately, plus the new one), and every deletion failed its test.
- The click-guard tests run a listener the screen has disabled, which a browser would not: they ask whether the handler refuses on its own.
- The confirmation test makes the decrypt fail, because drawing that screen starts a network fee estimate.
Disclosures:
- Judgement call: the same "cannot be derived" claim in two neighbouring comments (`selectedWalletDefect` in `addressDetail.js`, `gateOnWalletDefect` in `approval.js`) is corrected too.
- No user-facing wording changed; https://git.eeqj.de/sneak/AutistMask/issues/255 is open.
Model: opus-5-5
Each control that leads to a signature or to the private key now has a
test that it refuses a defective wallet before decrypting anything: Send
on the main, address and token screens, Export Private Key, and both
approval screens, as drawn and as clicked.
Send on the confirmation screen had no such check. The Send buttons
stand in front of it, but the popup reopens onto it from a saved view,
so it now refuses the same way.
The comments that said the wallet's key cannot be derived now say that
getSignerForAddress refuses it, and the walletDefects module comment
names both earlier import paths.
Model: opus-5-5
Rebased onto next at d0bbb3d: only TODO.md conflicted, resolved by keeping both Completed Steps entries, the one for #254 above the one for #253; nothing else changed.
Model: opus-5-5
Rebased onto `next` at `d0bbb3d`: only `TODO.md` conflicted, resolved by keeping both Completed Steps entries, the one for https://git.eeqj.de/sneak/AutistMask/issues/254 above the one for https://git.eeqj.de/sneak/AutistMask/issues/253; nothing else changed.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #254.
Each control that leads to a signature or to the private key now has a unit test in
tests/walletDefects.test.jsthat it refuses a defective wallet before decrypting anything: Send on the main, address and token screens, Export Private Key, and both approval screens, each checked as drawn (error shown, Approve disabled) and as clicked (no decrypt, nothing sent to the background).Confirmation screen. Its Send is now gated the same way, with a test. The Send buttons stand in front of it, but
confirm-txis a view the popup reopens onto from saved state, so they are not the only way onto it.Comments. The
walletDefects.jsmodule comment names both earlier import paths and says which one the depth check misjudges (7a7f9c5, in no tag). The export comment inaddressDetail.jsno longer says there is no key: it derives, andgetSignerForAddressrefuses it.Worth knowing:
Disclosures:
selectedWalletDefectinaddressDetail.js,gateOnWalletDefectinapproval.js) is corrected too.Model: opus-5-5
PASS
Model: opus-5-5
f2b17fbec6tod9a516e489Rebased onto
nextatd0bbb3d: onlyTODO.mdconflicted, resolved by keeping both Completed Steps entries, the one for #254 above the one for #253; nothing else changed.Model: opus-5-5
PASS
Model: opus-5-5