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

Always sign transactions and messages with the correct account #14

Merged
merged 1 commit into from
Mar 2, 2020

Conversation

Gudahtt
Copy link
Member

@Gudahtt Gudahtt commented Mar 2, 2020

The account used to sign transactions and messages should be the one the transaction or message is from. Instead, the last connected account was being used to sign any messages or transactions.

This was especially problematic considering the last connected account was not persisted, meaning that signatures were being performed with the wrong account after a reset (unless the last connected account happened to be account 0, which was the default).

A mapping of addresses to indexes as been added to the keyring state, and this mapping has been persisted. This should ensure the correct account index is used, and thus the correct hd path, each time this keyring is used for signing.

The account used to sign transactions and messages should be the one
the transaction or message is from. Instead, the last connected account
was being used to sign any messages or transactions.

This was especially problematic considering the last connected account
was not persisted, meaning that signatures were being performed with
the wrong account after a reset (unless the last connected account
happened to be account 0, which was the default).

A mapping of addresses to indexes as been added to the keyring state,
and this mapping has been persisted. This should ensure the correct
account index is used, and thus the correct hd path, each time this
keyring is used for signing.
index.js Show resolved Hide resolved
@whymarrh
Copy link
Contributor

whymarrh commented Mar 2, 2020

I can confirm that this does indeed sign transactions from nth accounts correctly, where n > 1

Copy link
Contributor

@whymarrh whymarrh left a comment

Choose a reason for hiding this comment

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

LGTM!

@Gudahtt Gudahtt requested a review from tmashuang March 2, 2020 20:57
@whymarrh
Copy link
Contributor

whymarrh commented Mar 2, 2020

The reproduction steps one can follow in MetaMask:

Before:

  1. Connect a Ledger account > 1 (e.g. the 2nd account)
  2. Confirm that sending a transaction is signed correctly
  3. Reload MetaMask (or, for non-MM, construct a new instance from serialized state)
  4. Confirm that sending a transaction is signed with the 1st account on the Ledger (an incorrect account)

After:

  1. Connect a Ledger account > 1 (e.g. the 2nd account)
  2. Confirm that sending a transaction is signed correctly
  3. Reload MetaMask (or, for non-MM, construct a new instance from serialized state)
  4. Confirm that sending a transaction is signed with the 2nd account on the Ledger (the correct account)

@whymarrh whymarrh mentioned this pull request Mar 2, 2020
@danfinlay danfinlay merged commit f32e529 into master Mar 2, 2020
@danfinlay danfinlay deleted the always-sign-with-correct-account branch March 2, 2020 22:58
julianariel pushed a commit to block-wallet/eth-ledger-bridge-keyring that referenced this pull request Apr 27, 2022
…ask#14)

The account used to sign transactions and messages should be the one
the transaction or message is from. Instead, the last connected account
was being used to sign any messages or transactions.

This was especially problematic considering the last connected account
was not persisted, meaning that signatures were being performed with
the wrong account after a reset (unless the last connected account
happened to be account 0, which was the default).

A mapping of addresses to indexes as been added to the keyring state,
and this mapping has been persisted. This should ensure the correct
account index is used, and thus the correct hd path, each time this
keyring is used for signing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants