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

Update ethereumjs-util to 5.1.3 #241

Merged
merged 2 commits into from Jan 12, 2018

Conversation

jchavarri
Copy link
Contributor

Fixes #156.

Still wrapping my head around the code, so any suggestions are welcomed. I just made sure the state tests were passing.

@@ -27,7 +27,7 @@ module.exports = function (opts) {

var publicKey
try {
publicKey = utils.ecrecover(msgHash, v, r, s)
publicKey = utils.ecrecover(msgHash, utils.bufferToInt(v), r, s)
Copy link
Member

@axic axic Dec 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is silently truncating the input to 53 bits. Since v must be either 0 or 1, it should be validated prior (without truncation).

I suggest something along the lines of:

v = new BN(v)
if (!v.eqn(0) && !v.eqn(1))
  // fail

and then within the ecrecover call it can use v.toNumber()

Copy link
Contributor Author

@jchavarri jchavarri Dec 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @axic.

This is silently truncating the input to 53 bits.

Afaik the validation happens in utils.bufferToInt. It throws for numbers larger than 53 bits, as it calls BN().toNumber and this call throws if that's the case.

Since v must be either 0 or 1, it should be validated prior

Should some extra validation be added to make sure it's 0 or 1? In case this validation fails, should the function just throw?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should some extra validation be added to make sure it's 0 or 1? In case this validation fails, should the function just throw?

There's no other way to fail there unfortunately.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since v must be either 0 or 1

Sorry, this actually wants 27 or 28 and ecrecover() itself will verify the range. I guess new BN(v).toNumber() could be a good compromise if we rely on ethereumjs-util to do the validation.

Copy link
Contributor Author

@jchavarri jchavarri Jan 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool, I hadn't seen ecrecover validated the input too.

I understand then that no further validation is needed here, as BN checks for the bit length and ethereumjs-util for the actual two-value range?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use BN(v).toNumber() here and not utils.bufferToInt(v)

lib/opFns.js Outdated
@@ -914,7 +914,7 @@ function memLoad (runState, offset, length) {

// shortcut
if (length.isZero()) {
return new Buffer('')
return Buffer.from('')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be replaced with Buffer.alloc(0).

lib/opFns.js Outdated
@@ -1023,7 +1023,7 @@ function makeCall (runState, callOptions, localOpts, cb) {
callOptions.depth = runState.depth + 1

// empty the return data buffer
runState.lastReturned = new Buffer([])
runState.lastReturned = Buffer.from([])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be replaced with Buffer.alloc(0).

@axic
Copy link
Member

axic commented Jan 5, 2018

Also this line could be replaced with Buffer.alloc(0): https://github.com/ethereumjs/ethereumjs-vm/blob/master/lib/runCall.js#L175

@jchavarri
Copy link
Contributor Author

@axic I applied the requested changes, let me know if there's anything else that needs to be updated, thanks!

@axic
Copy link
Member

axic commented Jan 12, 2018

@jchavarri thanks! Can you please apply #241 (comment), update to the latest ethereumjs-util release (there was one meanwhile) and use rebase instead of merging?

@jchavarri
Copy link
Contributor Author

@axic done!

One question, just curious: why using Bn over ethutil to convert to number in this case? Isn't the second using the first?

@axic
Copy link
Member

axic commented Jan 12, 2018

utils.bufferToInt tries to guess what the user wants to do and in the VM only bn.js is used directly, for safety and speed.

@axic axic changed the title Update ethereumjs-util to 5.1.2 Update ethereumjs-util to 5.1.3 Jan 12, 2018
@axic axic merged commit 869f832 into ethereumjs:master Jan 12, 2018
@jchavarri jchavarri deleted the update-ethereumjs-util-v5 branch January 12, 2018 15:57
holgerd77 added a commit that referenced this pull request Mar 11, 2021
Enforce hex prefixing for address strings
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

update to ethereumjs-util v5
3 participants