-
Notifications
You must be signed in to change notification settings - Fork 20.8k
signer/core: fix reference issue in key derivation #19827
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
signer/core: fix reference issue in key derivation #19827
Conversation
This seems like a bug in a specific derivation method. It should definitely not keep a pointer to the path, rather make a copy if it needs it. Where does it originate from though, Ledger and Trezor only use it for a request, but don't mutate it as far as I see it. |
Ah, indeed it does keep a reference. Please make a copy here: https://github.com/ethereum/go-ethereum/blob/master/accounts/usbwallet/wallet.go#L482. |
37c600b
to
5f46edc
Compare
@@ -479,7 +479,7 @@ func (w *wallet) Derive(path accounts.DerivationPath, pin bool) (accounts.Accoun | |||
|
|||
if _, ok := w.paths[address]; !ok { | |||
w.accounts = append(w.accounts, account) | |||
w.paths[address] = path | |||
copy(w.paths[address], path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't make a new copy. It retrieves w.paths[address]
, which will be an empty slice (nil) and then copy into it, limited to the length of the smallest operand (i.e. nil
, length of 0`) and return. I.e. this is a noop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I just saw debugging the other PR 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, we can make a Copy
method for accounts.DerivationPath
, might come in handy long term for Clef too.
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
* signer/core: fix reference issue in key derivation * Review feedback
Currently in
clé
clef
, the derivation process reuses the same derivation path array as input to theDerive
function. ThatDerive
function creates an account and keeps a pointer to the derivation path for other purposes.Since the derivation path gets updated each time
Derive
is called, all accounts end up having the rug pulled from under their feet: the derivation path they point to will be that of the first non-valid account.So this PR simply makes sure that one derivation path is allocated each time.