The typed data screen listed every key of the message, but ethers signs only the fields the type declares and drops the rest. A site could put a decoy spender beside the declared operator, or a note saying the signature only signs you in, and both read as signed lines (#539).
The Message section now follows the signed type: each declared field in the type's order, and inside a nested struct or a list item only that struct's declared fields. As settled on the issue, typed data with other keys is not refused. Each extra key is listed after the message under "Not part of the signature", with its place in the message (details.note, details[1].note) and its value. README SignApproval says so.
What the diff does not show:
A declared field missing from the message now gets a line reading undefined at the top level, and is left out of a nested struct's JSON. ethers refuses to sign typed data missing any declared field except a bool, which it signs as false.
The Domain section is unchanged: ethers signs every domain key that has a value and refuses one outside the EIP-712 domain fields, so nothing added there is shown as signed.
Judgement call: an extra key's place in the message is written as a path, such as details[1].note; the issue did not say how to name it.
Model: opus-5-5
The typed data screen listed every key of the message, but ethers signs only the fields the type declares and drops the rest. A site could put a decoy `spender` beside the declared `operator`, or a note saying the signature only signs you in, and both read as signed lines (https://git.eeqj.de/sneak/AutistMask/issues/539).
The Message section now follows the signed type: each declared field in the type's order, and inside a nested struct or a list item only that struct's declared fields. As settled on the issue, typed data with other keys is not refused. Each extra key is listed after the message under "Not part of the signature", with its place in the message (`details.note`, `details[1].note`) and its value. README SignApproval says so.
What the diff does not show:
- A declared field missing from the message now gets a line reading `undefined` at the top level, and is left out of a nested struct's JSON. ethers refuses to sign typed data missing any declared field except a `bool`, which it signs as false.
- The Domain section is unchanged: ethers signs every domain key that has a value and refuses one outside the EIP-712 domain fields, so nothing added there is shown as signed.
Judgement call: an extra key's place in the message is written as a path, such as `details[1].note`; the issue did not say how to name it.
Model: opus-5-5
ethers signs only the fields a type declares and drops any other key, but
the Message section listed every key the site sent, so an added key read
as signed. The Message section now follows the signed type, at every level
of nesting and in the type's order. Typed data with other keys is not
refused: those keys are listed after the message under "Not part of the
signature", by their place in the message. README SignApproval says so.
The operator/spender test now also checks the Message section, and new
tests cover an added key in a nested struct and in a list item.
Model: opus-5-5
PASS: the Message section now shows only the fields the signed type declares, at every level of nesting, and lists every other key under "Not part of the signature", as #539 asks.
Model: opus-5-5
PASS: the Message section now shows only the fields the signed type declares, at every level of nesting, and lists every other key under "Not part of the signature", as https://git.eeqj.de/sneak/AutistMask/issues/539 asks.
Model: opus-5-5
clawbot
merged commit f283a5bb91 into next2026-10-14 16:41:15 +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.
The typed data screen listed every key of the message, but ethers signs only the fields the type declares and drops the rest. A site could put a decoy
spenderbeside the declaredoperator, or a note saying the signature only signs you in, and both read as signed lines (#539).The Message section now follows the signed type: each declared field in the type's order, and inside a nested struct or a list item only that struct's declared fields. As settled on the issue, typed data with other keys is not refused. Each extra key is listed after the message under "Not part of the signature", with its place in the message (
details.note,details[1].note) and its value. README SignApproval says so.What the diff does not show:
undefinedat the top level, and is left out of a nested struct's JSON. ethers refuses to sign typed data missing any declared field except abool, which it signs as false.Judgement call: an extra key's place in the message is written as a path, such as
details[1].note; the issue did not say how to name it.Model: opus-5-5
PASS: the Message section now shows only the fields the signed type declares, at every level of nesting, and lists every other key under "Not part of the signature", as #539 asks.
Model: opus-5-5