Update ethereumjs-util to v6
frangio opened this issue · comments
The latest ethereumjs-util release is 6.1.0 and Ganache is still using 5.2.0.
I'm asking for this mainly because of this change that was introduced in 6.0.0:
[BREAKING] Fixed signature to comply with Geth and Parity in toRpcSig() changing
v from 0/1 to 27/28, this changes the resulting signature buffer
To protect devs from signature malleability OpenZeppelin has restricted the accepted signatures to those with v in range 27/28, thus Ganache generated signatures are not validating. See OpenZeppelin/openzeppelin-contracts#1622.
The specific change needed is in the utils.toRpcSig function used only here:
As an alternative fix, if updating this dependency is too much work at the moment, maybe we can just copy the new function and use it?
@frangio, thanks for reporting this issue! I'm in the process of reviewing a PR now that will update ethereumjs-util to the latest version #445 . That said, this is a bit more nuanced of an issue than it first appears and discussions regarding the implications are still on going: OpenZeppelin/openzeppelin-contracts#1622 (comment)
I'm hoping there is more clarity on this as soon as possible.
Hey @nicholasjpaterno! I've been following this issue as I'm one of the maintainers of ethereumjs.
My understanding is that the comment you linked is based on a misinterpretation of an internal change of Geth that shouldn't affect its users. Péter from the Geth team gave a nice explanation about it here.
Let me know if you have trouble updating any of the ethereumjs libraries. I'm happy to help.
Thanks, @alcuadrado. In order to not introduce a breaking change at this time I'm considering updating our usage of toRpcSig so it still generates the same output as it did previously (0/1 instead of 27/28). We only use toRpcSig in eth_sign.
What are your thoughts on Ganache keeping the 0/1 encoding (instead of 27/28) around for a bit longer?
I understand that it's a breaking change, so it should be introduced in your next major release. This behavior has been present for so long that changing it in a minor version will probably break too many things. I'm not 100% sure about this, as most people dealing with signatures already has code in place to somehow normalize them.
In my experience, this has always been a source of frustration when signing using Ganache or previous versions of ethereumjs-util. Until recently, using eth_sign wasn't that common though, but I believe that with the increased use of meta-transactions much more developers will encounter this problem. For this reason, I think that the sooner this change can be introduced, the better.
As a data point, I just confirmed with @frangio that OpenZeppelin's signature verification library only accepts 27/28, and it will be used in the Gas Station Network. Keeping 0/1 will lead to complications when testing projects that make use of either of them.