Empact
commented
6 years ago I would like to also remove the validate set, but if I do tests fail for reasons I don't understand, so I'm punting this to you.
1) PublicKey validating errors on creation errors if an invalid point is provided:
AssertionError: expected [Function] to throw an error
at Context.<anonymous> (test/publickey.js:31:22)
2) PublicKey validating errors on creation errors if a point not on the secp256k1 curve is provided:
AssertionError: expected [Function] to throw an error
at Context.<anonymous> (test/publickey.js:37:22)
3) PublicKey #getValidationError should recieve an invalid point error:
AssertionError: expected undefined to exist
4) PublicKey #getValidationError should recieve a boolean as false:
AssertionError: expected true to equal false
+ expected - actual
-true
+false
at Context.<anonymous> (test/publickey.js:140:20)
5) PublicKey #validate should throw an error if pubkey is invalid:
AssertionError: expected [Function] to throw an error
at Context.<anonymous> (test/publickey.js:412:22)
6) PublicKey #validate should throw an error if pubkey is invalid:
AssertionError: expected [Function] to throw an error
at Context.<anonymous> (test/publickey.js:419:22)
7) PublicKey #validate should throw an error if pubkey is infinity:
AssertionError: expected [Function] to throw an error
at Context.<anonymous> (test/publickey.js:425:22)
8) Point #validate should describe this point as invalid because of zero y:
AssertionError: expected [Function] to throw an error
at Context.<anonymous> (test/crypto/point.js:135:22)
9) Point #validate should describe this point as invalid because of invalid y:
AssertionError: expected [Function] to throw an error
at Context.<anonymous> (test/crypto/point.js:144:22)
10) Point #validate should describe this point as invalid because out of curve bounds:
AssertionError: expected [Function] to throw an error
at Context.<anonymous> (test/crypto/point.js:158:22)
matiu
oxfn
mohammadrafigh
Point's prototype is set to the prototype of
ec('secp256k1').curve.point(), which means the library itself is global state, and mutation to it is shared across users of 'elliptic'.This is not generally a problem, for example, with
validateit's a simple set, so the greatest risk is that it will be directly overwritten.But in the case of
getXandgetY, both methods are overwritten with others that depend on the prior implementation as stored in_get*. If this happens twice, then the implementation of_getXis replaced with something that depends on a call to_getX, and the callers is stuck in an infinite loop.Here's an example of the infinite loop, which I came across by interaction between bitcore-lib-dash and zcash-bitcore-lib, but by inspection it seems they are both downstream of this code.