Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix serious issue in .toString(16) #295

Merged
merged 2 commits into from
May 24, 2022
Merged

Conversation

alexdupre
Copy link
Contributor

In some circumstances the hex encoding of big numbers is wrong. In addition to a display issue, given that the the hex string if often used as an intermediate representation in transport/conversion scenarios, the re-constructed big number can actually change its value, creating serious issues.

The hex encoding of some numbers is wrong. Since the string representation
is also used for interoperability between BigInt libraries, this bug is
causing a number modification when a BN.js number is converted into
another BigInt class, for example the BigNumber of ethers.js.
@ricmoo
Copy link

ricmoo commented May 17, 2022

FYI, I have confirmed this issue.

@indutny Would you have an idea of when you would be able to get to this? I am debating including a hack to fix this temporarily into ethers if you don’t have time to get to it. :)

@fanatid
Copy link
Collaborator

fanatid commented May 18, 2022

@alexdupre thanks for the fix. Can you explain what's wrong with current code and how moving if-block will fix it? Test is a good but it would be great to have explanation for the future.

@alexdupre
Copy link
Contributor Author

The issue is present when these conditions are true:

  1. the code is processing the last word
  2. carry is 0
  3. off is 24 at the start of the iteration

In this case the if doesn't add the full 0-padded 6 characters, because it thinks it's the last iteration, but actually because of the off increment (and consequentially the i decrement) this is the second last iteration, and the full 6 chars have to be added. Does it make sense?

@fanatid
Copy link
Collaborator

fanatid commented May 18, 2022

Make sense, thanks.
I wanted release this as patch but in the same time changes can break something, maybe we should proceed with minor? Any thoughts?

@alexdupre
Copy link
Contributor Author

alexdupre commented May 18, 2022

If you are 100% sure that the fix is correct, then I think it should be released as patch, this is a serious issue and there cannot be external code that relies on such broken behavior. Personally I don't think this fix can break anything.

@fanatid
Copy link
Collaborator

fanatid commented May 18, 2022

I think changes are correct but it would be great if somebody except @ricmoo confirmed that everything is correct.

@alexdupre
Copy link
Contributor Author

FWIW I think this may be a good candidate for a property-based testing methodology (it'd be interesting to know if it would have spotted this issue as well).

@alexdupre
Copy link
Contributor Author

Any update?

@fanatid fanatid merged commit 042ab62 into indutny:master May 24, 2022
@fanatid
Copy link
Collaborator

fanatid commented May 24, 2022

Thank you for the reminder! Published as v5.2.1.

@ricmoo
Copy link

ricmoo commented May 24, 2022

@fanatid Could I bug you to also get the version in elliptic bumped to match this too, please? :)

@fanatid
Copy link
Collaborator

fanatid commented May 24, 2022

Only @indutny can do this :/

legobeat added a commit to legobeat/ethjs-abi that referenced this pull request Jan 10, 2023
legobeat added a commit to legobeat/number-to-bn that referenced this pull request Jan 10, 2023
legobeat added a commit to legobt/ethjs-abi that referenced this pull request Jan 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants