Update ethereumjs-util to v6

[frangio]

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.

[frangio]

The specific change needed is in the utils.toRpcSig function used only here:

https://github.com/trufflesuite/ganache-core/blob/cba166610008262266a60908d7ab4eb20fd856be/lib/statemanager.js#L449

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?

https://github.com/ethereumjs/ethereumjs-util/blob/599ba5b1c7043a7e155e6032c50d7a01fc63aaf1/src/signature.ts#L52-L64

[nicholasjpaterno]

@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.

[alcuadrado]

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.

[davidmurdoch]

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?

[alcuadrado]

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.

[davidmurdoch]

Closed by #445. Major version bump plan to handle the breaking change can be tracked here: #451