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
Settled, but not as first recommended: keep eth_sign and make the warning and README.md say what the code does. The Ethereum JSON-RPC specification defines eth_sign as an EIP-191 signature over the data (the "Ethereum Signed Message" prefix), which is exactly what this wallet produces. Raw-hash signing, which the warning describes, is a non-standard variant and the dangerous one. So the code already does the specified, safe thing, and README.md lists eth_sign as supported; dropping it would only break sites that use it as specified. Easy to reverse either way.
Plan: replace the raw-hash danger warning with a plain sentence saying the site used the older eth_sign method and the data will be signed as a personal message; correct README.md's SignApproval section to match; confirm eth_sign's parameters are read address first, then data, and pin both the order and the signature with a test.
Model: opus-5-5
Settled, but not as first recommended: keep `eth_sign` and make the warning and `README.md` say what the code does. The Ethereum JSON-RPC specification defines `eth_sign` as an EIP-191 signature over the data (the "Ethereum Signed Message" prefix), which is exactly what this wallet produces. Raw-hash signing, which the warning describes, is a non-standard variant and the dangerous one. So the code already does the specified, safe thing, and `README.md` lists `eth_sign` as supported; dropping it would only break sites that use it as specified. Easy to reverse either way.
Plan: replace the raw-hash danger warning with a plain sentence saying the site used the older `eth_sign` method and the data will be signed as a personal message; correct `README.md`'s SignApproval section to match; confirm `eth_sign`'s parameters are read address first, then data, and pin both the order and the signature with a test.
Model: opus-5-5
sneak
was unassigned by clawbot2026-10-14 03:59:17 +02:00
clawbot
self-assigned this 2026-10-14 03:59:17 +02:00
Built in #545. The eth_sign warning now reads "This site used the older eth_sign method. The data will be signed as a personal message.", and README.md's SignApproval section says the same. A test pins that eth_sign is read address first, data second, and that the page gets the personal message signature over the data. The signing code is unchanged.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/AutistMask/pulls/545. The `eth_sign` warning now reads "This site used the older eth_sign method. The data will be signed as a personal message.", and `README.md`'s SignApproval section says the same. A test pins that `eth_sign` is read address first, data second, and that the page gets the personal message signature over the data. The signing code is unchanged.
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.
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)
Settled, but not as first recommended: keep
eth_signand make the warning andREADME.mdsay what the code does. The Ethereum JSON-RPC specification defineseth_signas an EIP-191 signature over the data (the "Ethereum Signed Message" prefix), which is exactly what this wallet produces. Raw-hash signing, which the warning describes, is a non-standard variant and the dangerous one. So the code already does the specified, safe thing, andREADME.mdlistseth_signas supported; dropping it would only break sites that use it as specified. Easy to reverse either way.Plan: replace the raw-hash danger warning with a plain sentence saying the site used the older
eth_signmethod and the data will be signed as a personal message; correctREADME.md's SignApproval section to match; confirmeth_sign's parameters are read address first, then data, and pin both the order and the signature with a test.Model: opus-5-5
Built in #545. The
eth_signwarning now reads "This site used the older eth_sign method. The data will be signed as a personal message.", andREADME.md's SignApproval section says the same. A test pins thateth_signis read address first, data second, and that the page gets the personal message signature over the data. The signing code is unchanged.Model: opus-5-5