-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[Bug]: tx sign doesn't throw an error when incorrect Ledger is used #19690
Comments
I have an approach that will at least throw an error after a user has attempted to sign with their Ledger. Apply the diff below: here // Sign those bytes
- sigBytes, _, err := txf.keybase.Sign(name, bytesToSign)
+ sigBytes, ledgerPubKey, err := txf.keybase.Sign(name, bytesToSign)
if err != nil {
return err
}
+ if !pubKey.Equals(ledgerPubKey) {
+ return fmt.Errorf("pubkey mismatch: %s ≠ %s", pubKey, ledgerPubKey)
+ } which results in:
I think a better approach would be to inform the user even prior to them trying to sign but I don't see a way to do that yet. |
I figured out an approach that will error before the user attempts to sign. Will publish a PR shortly. The important part of the diff is in keyring.go + ledgerPubKey := priv.PubKey()
+ pubKey, err := k.GetPubKey()
+ if err != nil {
+ return nil, nil, err
+ }
+ if !pubKey.Equals(ledgerPubKey) {
+ return nil, nil, fmt.Errorf("the public key that the user attempted to sign with %v does not match the public key on the ledger device %v", pubKey.String(), ledgerPubKey.String())
+ } which results in
I think there's probably a better way to print those public keys but defer to Cosmos SDK maintainers. |
Ahh while attempting to upstream, I discovered #14460 which wasn't backported to v0.46.x. Hmm, I don't see why the signature needs to be made to return the error. The approach in Zaki's PR returns an error after the user has signed with their Ledger but we can error before they sign with the diff above. |
Cosmos SDK Version
0.46
Is there an existing issue for this?
What happened
It looks like there's a bug when transactions are signed with the incorrect Ledger. In my scenario, I plugged in a Ledger that does not contain a key corresponding to the value provided for the
--from
flag but thetx sign
command generates a signature and includes the pub key from the value provided for the--from
flag. This means the user gets no signal that they created a output document that is invalid because the signature wasn't generated using the secret key of the pub key in the output document. The user only learns of their error later when the output document is combined with other output documents (i.e. in themulti-sign
step).What I would expect to happen
An error to be thrown informing the user that the key specified for the
--from
flag does not match the keys present on the Ledger.How to reproduce?
The repro steps are a bit involved but I created a gist which can be used to repro on celestia-app. You'll need two Ledgers. The rough steps are:
--from test3 --ledger
and LedgerB plugged in.The text was updated successfully, but these errors were encountered: