Before the release candidate, read the code that signs, approves and holds keys, line by line, for correctness against README.md and the standards it implements. This is a defect hunt, not a redesign: deliberate behaviour README.md documents is not a defect.
Scope
Key handling: src/shared/vault.js, src/shared/wallet.js, the create and import paths in src/popup/views/addWallet.js, the recovery-phrase and private-key screens, delete wallet and the lost-password route, and where the decrypted secret lives and how long.
Approvals: request handling and the approval lifecycle in src/background/index.js (origin and sender checks, pending approvals, window close, remembered sites, network switching), src/shared/approvalTx.js, src/shared/approvalVerify.js, and src/popup/views/approval.js.
Signing: personal_sign, eth_sign, typed data (eth_signTypedData_v4 and eth_signTypedData), eth_sendTransaction, and the popup's own send in src/popup/views/confirmTx.js: is what the user is shown exactly what is signed and sent, on the chain they think, from the address they think.
The decoders feeding the approval screen (src/shared/uniswap.js and the ERC-20 decoding), only where a wrong decode could show the user something other than what is signed.
Definition of done
Each real defect is filed as its own issue: where (file and line), a concrete failure scenario, a severity (critical, major, minor), and a definition of done.
One closing comment on this issue linking the issues filed.
No code changes and no PR.
Model: opus-5-5
Before the release candidate, read the code that signs, approves and holds keys, line by line, for correctness against `README.md` and the standards it implements. This is a defect hunt, not a redesign: deliberate behaviour `README.md` documents is not a defect.
## Scope
- Key handling: `src/shared/vault.js`, `src/shared/wallet.js`, the create and import paths in `src/popup/views/addWallet.js`, the recovery-phrase and private-key screens, delete wallet and the lost-password route, and where the decrypted secret lives and how long.
- Approvals: request handling and the approval lifecycle in `src/background/index.js` (origin and sender checks, pending approvals, window close, remembered sites, network switching), `src/shared/approvalTx.js`, `src/shared/approvalVerify.js`, and `src/popup/views/approval.js`.
- Signing: `personal_sign`, `eth_sign`, typed data (`eth_signTypedData_v4` and `eth_signTypedData`), `eth_sendTransaction`, and the popup's own send in `src/popup/views/confirmTx.js`: is what the user is shown exactly what is signed and sent, on the chain they think, from the address they think.
- The decoders feeding the approval screen (`src/shared/uniswap.js` and the ERC-20 decoding), only where a wrong decode could show the user something other than what is signed.
## Definition of done
- [ ] Each real defect is filed as its own issue: where (file and line), a concrete failure scenario, a severity (critical, major, minor), and a definition of done.
- [ ] One closing comment on this issue linking the issues filed.
- [ ] No code changes and no PR.
Model: opus-5-5
clawbot
self-assigned this 2026-10-14 03:59:39 +02:00
Read the signing, approval and key-handling code on next (8e52528). Filed:
#524: switching network in Settings under the confirmation screen sends the transfer on the new network (critical)
#539: the typed data screen lists message keys that are not signed (major)
#526: a connection allowed without "Remember" ends when the background worker idles (minor)
#527: a page with an opaque origin is treated as a site named null (minor)
#535: the swap decoder lists Execute Sub-Plan as a V3 exact-out swap (minor)
This read also found three defects already filed from #506, so they were not filed again: #510, #519 and #520.
Not run, and not filed: whether Chrome keeps the background worker alive while a transaction or signature approval waits for the user. Pending approvals are held in memory, as the connections in #526 are, so a worker stopped during a long read would lose the approval. That needs a real browser to settle.
Model: opus-5-5
Read the signing, approval and key-handling code on `next` (8e52528). Filed:
- https://git.eeqj.de/sneak/AutistMask/issues/524: switching network in Settings under the confirmation screen sends the transfer on the new network (critical)
- https://git.eeqj.de/sneak/AutistMask/issues/539: the typed data screen lists message keys that are not signed (major)
- https://git.eeqj.de/sneak/AutistMask/issues/526: a connection allowed without "Remember" ends when the background worker idles (minor)
- https://git.eeqj.de/sneak/AutistMask/issues/527: a page with an opaque origin is treated as a site named `null` (minor)
- https://git.eeqj.de/sneak/AutistMask/issues/535: the swap decoder lists Execute Sub-Plan as a V3 exact-out swap (minor)
This read also found three defects already filed from https://git.eeqj.de/sneak/AutistMask/issues/506, so they were not filed again: https://git.eeqj.de/sneak/AutistMask/issues/510, https://git.eeqj.de/sneak/AutistMask/issues/519 and https://git.eeqj.de/sneak/AutistMask/issues/520.
Not run, and not filed: whether Chrome keeps the background worker alive while a transaction or signature approval waits for the user. Pending approvals are held in memory, as the connections in https://git.eeqj.de/sneak/AutistMask/issues/526 are, so a worker stopped during a long read would lose the approval. That needs a real browser to settle.
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.
Before the release candidate, read the code that signs, approves and holds keys, line by line, for correctness against
README.mdand the standards it implements. This is a defect hunt, not a redesign: deliberate behaviourREADME.mddocuments is not a defect.Scope
src/shared/vault.js,src/shared/wallet.js, the create and import paths insrc/popup/views/addWallet.js, the recovery-phrase and private-key screens, delete wallet and the lost-password route, and where the decrypted secret lives and how long.src/background/index.js(origin and sender checks, pending approvals, window close, remembered sites, network switching),src/shared/approvalTx.js,src/shared/approvalVerify.js, andsrc/popup/views/approval.js.personal_sign,eth_sign, typed data (eth_signTypedData_v4andeth_signTypedData),eth_sendTransaction, and the popup's own send insrc/popup/views/confirmTx.js: is what the user is shown exactly what is signed and sent, on the chain they think, from the address they think.src/shared/uniswap.jsand the ERC-20 decoding), only where a wrong decode could show the user something other than what is signed.Definition of done
Model: opus-5-5
Read the signing, approval and key-handling code on
next(8e52528). Filed:null(minor)This read also found three defects already filed from #506, so they were not filed again: #510, #519 and #520.
Not run, and not filed: whether Chrome keeps the background worker alive while a transaction or signature approval waits for the user. Pending approvals are held in memory, as the connections in #526 are, so a worker stopped during a long read would lose the approval. That needs a real browser to settle.
Model: opus-5-5