fix: viem adapter must treat raw byte messages as raw in verifyMessage - #993
Open
gomesalexandre wants to merge 1 commit into
Open
fix: viem adapter must treat raw byte messages as raw in verifyMessage#993gomesalexandre wants to merge 1 commit into
gomesalexandre wants to merge 1 commit into
Conversation
ViemUtils.verifyMessage decoded a Uint8Array message as UTF-8 text via
TextDecoder before recovering the signer, instead of passing it through
as raw bytes. Any binary message that isn't valid UTF-8 - notably an
order digest hashed for ETHSIGN and passed via decodeSignatureOwner -
gets silently mangled, so the recovered address never matches the real
signer. ViemSignerAdapter.signMessage already handles the identical
Uint8Array case correctly via viem's `{ raw }` form; verifyMessage just
never got the same treatment, and ethers-v5/v6 verifyMessage handle
Uint8Array as raw bytes natively, so the drift was viem-only.
Adds a regression test that signs an order with ETHSIGN across all
three adapters and recovers the owner via decodeSignatureOwner - it
only fails for viem on the old code.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
|
Warning Review limit reachedNext included review available in 14 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ViemUtils.verifyMessagedecoded aUint8Arraymessage as UTF-8 text viaTextDecoderbefore recovering the signer, instead of passing it through to viem as raw bytes.Any binary message that isn't valid UTF-8 - notably an order digest hashed for the ETHSIGN signing scheme and passed via
decodeSignatureOwner(packages/contracts-ts/src/settlement.ts) - gets silently mangled by the UTF-8 decode (replacement characters on invalid byte sequences) before being re-hashed with thepersonal_signprefix, so the recovered address never matches the real signer.ViemSignerAdapter.signMessagealready handles the identicalUint8Arraycase correctly, using viem's{ raw: bytes }message form (packages/providers/viem-adapter/src/ViemSignerAdapter.ts:37-48) - so signing an ETHSIGN order with the viem adapter works fine, but verifying/recovering its owner does not.ethers-v5/ethers-v6'sverifyMessagehandle aUint8Arrayas raw bytes natively, so this drift was viem-only.Fix
Use
{ raw: message }for theUint8Arraybranch inViemUtils.verifyMessage, matching the conventionViemSignerAdapter.signMessagealready uses.Test
Added
packages/contracts-ts/tests/decodeSignatureOwner.test.ts: signs a test order with the ETHSIGN scheme across all three adapters (ethers-v5, ethers-v6, viem) using the real per-adapter signer, then recovers the owner viadecodeSignatureOwnerand asserts it matches the signer's address.No existing test exercised
decodeSignatureOwnerfor the ETHSIGN scheme, or the viem adapter's raw-byte message path, at all - this was a real, silent, untested correctness gap in owner/signature verification specific to the viem adapter.Risk
Low -
verifyMessage's string branch is untouched; only theUint8Arraybranch changes, from an incorrect UTF-8 decode to the raw-bytes form viem itself documents and that the adapter's own signer already uses.