clawbot
13d444c3aa
All checks were successful
check / check (push) Successful in 33s
The seam between the content script, the inpage provider, the background worker
and the approval popup had no coverage at all. The unit suite covers each side
in isolation, so a wallet that signed the wrong payload, handed back a signature
from the wrong key, hung on a rejected prompt, or put the user's password back
on the extension messaging boundary would have passed everything.
Ten end-to-end tests now drive it. The route handler serves a local test page on
a reserved-TLD origin; window.ethereum arrives there from the shipped MAIN-world
content script, not from anything the fixture installs, and the page's own
EIP-6963 announcement is required to be that provider by object identity. The
page then speaks eth_requestAccounts, personal_sign, eth_signTypedData_v4 and
eth_sendTransaction through the real prompts, approved and rejected.
The assertions are the point:
- every signature is recovered in the runner with verifyMessage,
verifyTypedData and Transaction.from(), and compared against the active
address read out of extension storage. The background verifies too; nothing
here leans on its verdict.
- the transaction is checked against the raw signed bytes captured at
eth_sendRawTransaction, which the RPC stub now records and answers with the
transaction's real hash. Signer, recipient, value, call data and chain id
are all compared there, and the hash the page received is required to be the
hash of those bytes.
- a rejected prompt must reach the page as a rejection rather than hang or
resolve, and must carry EIP-1193 code 4001 across the boundary. The code is
asserted on the wire because that is where it survives: the inpage provider
rebuilds the rejection as a bare Error, so the calling page catches a message
and no code. Reported, not asserted either way.
- the password must appear in no message the approval window sends to the
background, observed directly by wrapping chrome.runtime.sendMessage before
Approve is clicked, with the response message that would carry it required
to be present so the check cannot pass on an empty record.
Every one of those was run against a deliberately broken variant and seen to
fail: a corrupted recovered signer, a payload carrying the password again, a
provider that resolves instead of rejecting, and approval screens displaying the
wrong message, value and call data.
Two honest limits. The RPC is stubbed throughout, so this does not discharge a
real dApp with real funds against a real network. And the site-connection prompt
goes through chrome.action.openPopup(), whose browser-action popup headless
Chromium will not expose as a page, so that one prompt is driven at the URL the
extension puts on the action instead — same page, same approval id, but a real
toolbar click is not observable from a headless harness. Both are stated in
README.md rather than presented as covered.
Test-only: nothing under src/ changes.