Bump eth-sig-util to 2.3.0

[whymarrh]

Closes #6661, refs MetaMask/eth-sig-util#51

[Gudahtt]

On #6661, @danfinlay mentioned having to update the keyrings to use the new version of eth-sig-util as well. That hasn't been done yet - they're still on 1.x.

This change seems fine either way - we were already using 2.x. I'm wondering what the consequences of our dependencies using the older eth-sig-util might be though - whether any expectations about these signatures bleed across package boundaries. 🤔

[danfinlay]

The reason this was listed as a breaking semver change (eth-sig-util@>=2.x.x is because the signTypedData method was assigned a new name. We should make sure we are pointing to the correct method in this PR:
https://github.com/MetaMask/eth-sig-util/pull/20/files

[danfinlay]

Looks like Mark already raised my concern, feel free to dismiss my review, I just mean that we should make sure it still works the same, like on the signature test site:
https://danfinlay.github.io/js-eth-personal-sign-examples/

[whymarrh]

On #6661, @danfinlay mentioned having to update the keyrings to use the new version of eth-sig-util as well. That hasn't been done yet - they're still on 1.x.

Updated to bump eth-keyring-controller as well. It is a major version bump but looking at the commits it's all dependency version bumps.^[1]

I believe this change now accomplishes what we need—I don't think the other instances of the module are important in this context. npm ls --production eth-sig-util:

├─┬ [email protected]
│ └─┬ [email protected]
│   └── [email protected] 
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └── [email protected]  deduped
│ ├── [email protected] 
│ └─┬ [email protected]
│   └── [email protected]  deduped
├─┬ [email protected]
│ └── [email protected] 
├── [email protected] 
├─┬ [email protected]
│ └── [email protected] 
└─┬ [email protected]
  ├─┬ [email protected]
  │ ├─┬ [email protected]
  │ │ └── [email protected]  deduped
  │ ├── [email protected] 
  │ └─┬ [email protected]
  │   └── [email protected]  deduped
  ├── [email protected] 
  └─┬ UNMET DEPENDENCY web3-provider-engine@github:metamask/provider-engine#e91367bc2c2535fbf7add06244d9d4ec98620042
    └── UNMET DEPENDENCY [email protected] 

By module:

• [email protected] using [email protected] only uses #recoverPersonalSign^[2]
• [email protected] using [email protected] directly only uses #normalize^[3]
• [email protected] using [email protected] does not support signTypedData^[4]
• [email protected] using [email protected] does not support signTypedData^[5]
• [email protected] we are using only select controllers from, none of which deal with signing

I'm wondering what the consequences of our dependencies using the older eth-sig-util might be though - whether any expectations about these signatures bleed across package boundaries. — @Gudahtt

That's a valid concern and something we should audit. I imagine we can/will run into issues with the version mix we have (e.g. if normalize were to behave differently across versions or something like that). A separate concern though, I believe.

The reason this was listed as a breaking semver change (eth-sig-util@>=2.x.x is because the signTypedData method was assigned a new name. We should make sure we are pointing to the correct method [...] — @danfinlay

The extension was already on 2.x so it shouldn't need undergo any changes for us to bump the direct dependency. Looking at the API for the KeyringController, bumping that as well shouldn't require extension changes.

That said, I did test this with the signature site and it looks good to me. Maybe @tmashuang can also give it his seal of approval? I've add @brunobar79 to the reviewers here as well for good measure.

[Gudahtt]

Sounds reasonable to me 👍

[danfinlay]

Looks like @whymarrh did the due diligence, thanks!