Where.src/popup/views/approval.js:808-811 (both eth_sign and personal_sign call signer.signMessage(getBytes(message))); src/shared/approvalVerify.js:570-575 (verified with verifyMessage); src/background/index.js:864-868 (the eth_sign danger warning); README
SignApproval.
The behaviour.eth_sign is implemented identically to personal_sign — an
EIP-191 prefixed message signature — not the raw 32-byte hash signature that eth_sign denotes. So the danger warning ("this site is requesting to sign a raw
hash … can be used to sign transactions that drain your funds") and the README
describe something the code does not do, and a dApp that asks for eth_sign
expecting raw-hash semantics receives an incompatible signature. There is no key
risk today, because the safe behaviour is what runs.
The question. Keep eth_sign as a personal_sign alias, or drop it?
Options.
Drop eth_sign: answer EIP-1193 4200 (unsupported) and remove the warning
and the README claim.
Keep the alias: correct the warning and the README to say the request is signed
as a personal message.
Recommendation. Drop eth_sign — it is legacy, unsafe by design, and this
implementation does not provide its semantics anyway; answering 4200 is honest
and removes an untrue warning.
Definition of done.
The owner rules drop vs keep-and-relabel.
The warning text and the README are made true to what the code does, or eth_sign is removed and answered 4200.
A test pins the chosen behaviour.
Model: fable-5-1 (review); opus-4-8 (filing)
Severity: hardening. Owner decision.
**Where.** `src/popup/views/approval.js:808-811` (both `eth_sign` and
`personal_sign` call `signer.signMessage(getBytes(message))`);
`src/shared/approvalVerify.js:570-575` (verified with `verifyMessage`);
`src/background/index.js:864-868` (the `eth_sign` danger warning); README
SignApproval.
**The behaviour.** `eth_sign` is implemented identically to `personal_sign` — an
EIP-191 prefixed message signature — not the raw 32-byte hash signature that
`eth_sign` denotes. So the danger warning ("this site is requesting to sign a raw
hash … can be used to sign transactions that drain your funds") and the README
describe something the code does not do, and a dApp that asks for `eth_sign`
expecting raw-hash semantics receives an incompatible signature. There is no key
risk today, because the safe behaviour is what runs.
**The question.** Keep `eth_sign` as a `personal_sign` alias, or drop it?
**Options.**
- Drop `eth_sign`: answer EIP-1193 `4200` (unsupported) and remove the warning
and the README claim.
- Keep the alias: correct the warning and the README to say the request is signed
as a personal message.
**Recommendation.** Drop `eth_sign` — it is legacy, unsafe by design, and this
implementation does not provide its semantics anyway; answering `4200` is honest
and removes an untrue warning.
**Definition of done.**
- [ ] The owner rules drop vs keep-and-relabel.
- [ ] The warning text and the README are made true to what the code does, or
`eth_sign` is removed and answered `4200`.
- [ ] A test pins the chosen behaviour.
Model: fable-5-1 (review); opus-4-8 (filing)
sneak
was assigned by clawbot2026-09-21 20:37:57 +02:00
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.
Severity: hardening. Owner decision.
Where.
src/popup/views/approval.js:808-811(botheth_signandpersonal_signcallsigner.signMessage(getBytes(message)));src/shared/approvalVerify.js:570-575(verified withverifyMessage);src/background/index.js:864-868(theeth_signdanger warning); READMESignApproval.
The behaviour.
eth_signis implemented identically topersonal_sign— anEIP-191 prefixed message signature — not the raw 32-byte hash signature that
eth_signdenotes. So the danger warning ("this site is requesting to sign a rawhash … can be used to sign transactions that drain your funds") and the README
describe something the code does not do, and a dApp that asks for
eth_signexpecting raw-hash semantics receives an incompatible signature. There is no key
risk today, because the safe behaviour is what runs.
The question. Keep
eth_signas apersonal_signalias, or drop it?Options.
eth_sign: answer EIP-11934200(unsupported) and remove the warningand the README claim.
as a personal message.
Recommendation. Drop
eth_sign— it is legacy, unsafe by design, and thisimplementation does not provide its semantics anyway; answering
4200is honestand removes an untrue warning.
Definition of done.
eth_signis removed and answered4200.Model: fable-5-1 (review); opus-4-8 (filing)