Fix: Prevent .eth.eth Suffix in bytesToPacket Decoding#263
Open
st-mn wants to merge 2 commits intoensdomains:mainfrom
Open
Fix: Prevent .eth.eth Suffix in bytesToPacket Decoding#263st-mn wants to merge 2 commits intoensdomains:mainfrom
st-mn wants to merge 2 commits intoensdomains:mainfrom
Conversation
Problem When decoding DNS-encoded ENS names using bytesToPacket, certain packet bytes (e.g., 0x08383433362E6574680365746800) would incorrectly produce names with a double .eth suffix, such as 8436.eth.eth instead of the expected 8436.eth. This occurs when the encoded packet contains two labels: one that already ends with .eth and a trailing eth label, leading to an erroneous concatenation. Solution This PR updates the bytesToPacket function in hexEncodedName.ts to handle this edge case: After decoding the labels, if the last label is 'eth' and the previous label already ends with '.eth', the function removes the trailing 'eth' label before joining the labels. This ensures that names like 8436.eth.eth are correctly normalized to 8436.eth, while still allowing valid cases such as [labelhash].eth to decode as expected. Implementation Details The function now checks the decoded label array for the described pattern and mutates the array accordingly before joining. The logic is robust against other edge cases and does not affect names that are supposed to end with .eth. Testing Added/updated unit tests in hexEncodedName.test.ts to cover the problematic case and ensure no regression for other valid ENS names. All tests pass, confirming the fix. References Fixes: ensdomains#222 Context: namehash/ensnode#36 (comment) new file: packages/ensjs/src/utils/hexEncodedName.test.ts modified: packages/ensjs/src/utils/hexEncodedName.ts
modified: packages/ensjs/src/utils/hexEncodedName.ts
|
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
1 participant
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.
Fix: Prevent .eth.eth Suffix in bytesToPacket Decoding
Problem
When decoding DNS-encoded ENS names using bytesToPacket, certain packet bytes (e.g., 0x08383433362E6574680365746800) would incorrectly produce names with a double .eth suffix, such as 8436.eth.eth instead of the expected 8436.eth. This occurs when the encoded packet contains two labels: one that already ends with .eth and a trailing eth label, leading to an erroneous concatenation.
Solution
This PR updates the bytesToPacket function in hexEncodedName.ts to handle this edge case:
After decoding the labels, if the last label is 'eth' and the previous label already ends with '.eth', the function removes the trailing 'eth' label before joining the labels.
This ensures that names like 8436.eth.eth are correctly normalized to 8436.eth, while still allowing valid cases such as [labelhash].eth to decode as expected.
Implementation Details
The function now checks the decoded label array for the described pattern and mutates the array accordingly before joining.
Testing
Added/updated unit tests in hexEncodedName.test.ts to cover the problematic case and ensure no regression for other valid ENS names.
All tests pass, confirming the fix.
References
Fixes: #222
Context: namehash/ensnode#36 (comment)