-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
feat: add customized Ledger support #12935
Conversation
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.
utACK
I left a few minor comments and we also need a changelog entry for this as well as a note in the upgrading doc IMO
@@ -144,6 +144,15 @@ type Options struct { | |||
SupportedAlgos SigningAlgoList | |||
// supported signing algorithms for Ledger | |||
SupportedAlgosLedger SigningAlgoList | |||
// define Ledger Derivation function | |||
LedgerDerivation func() (ledger.SECP256K1, error) |
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.
Can't ledger derive keys that aren't on the SECP curve?
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.
Currently, Ledger devices are represented using the SECP256k1
interface. This PR intended only to generalize Ledger support within the realm of secp256k1 keys, but it's possible that generalizing it even further might be more appropriate. Do you think that would be the case?
crypto/ledger/ledger_secp256k1.go
Outdated
} else { | ||
return convertDERtoBER(sig) | ||
} |
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.
} else { | |
return convertDERtoBER(sig) | |
} | |
} | |
return convertDERtoBER(sig) |
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.
Revised
// a connected Ledger device. | ||
var discoverLedger discoverLedgerFn | ||
// options stores the Ledger Options that can be used to customize Ledger usage | ||
var options Options |
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.
is there a way to not use a private global? Or is this inherent to how the ledger is setup and used?
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.
The implementation of the Ledger functions depends on the options provided, so there must be some form of local state. Let me know if there is a way to improve it, I am open to any ideas.
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.
Could we use dependency injection here @kocubinski?
crypto/ledger/ledger_real.go
Outdated
// Set default values for Cosmos Ledger instance. These can be updated | ||
// by setting fields in the Keyring Options. | ||
options.createPubkey = func(key []byte) types.PubKey { | ||
return &secp256k1.PubKey{Key: key} | ||
} | ||
options.appName = "Cosmos" | ||
options.skipDERConversion = false |
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.
There's two code blocks that do the exact same thing -- I would move this setup into a helper function.
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.
Revised
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.
utACK
@austinchandra could you allow access for us to update your branch or just rebase |
dbcf92a
to
37ae302
Compare
@alexanderbez Rebased and added |
@austinchandra could you quickly address the linting errors and we'll merge 👍 |
2b8dd66
to
03acc49
Compare
@alexanderbez Fixed and updated |
03acc49
to
d8ef53d
Compare
@austinchandra can you allow access to update your branches for us? That way we can rebase |
d8ef53d
to
6d61f0a
Compare
@alexanderbez Rebased and granted permissions |
6d61f0a
to
5b385e2
Compare
Codecov Report
@@ Coverage Diff @@
## main #12935 +/- ##
==========================================
- Coverage 54.02% 53.71% -0.31%
==========================================
Files 645 645
Lines 55238 55271 +33
==========================================
- Hits 29841 29690 -151
- Misses 23019 23198 +179
- Partials 2378 2383 +5
|
@@ -262,6 +263,13 @@ func (ctx Context) WithAux(isAux bool) Context { | |||
return ctx | |||
} | |||
|
|||
// WithLedgerHasProto returns the context with the provided boolean value, indicating | |||
// whether the target Ledger application can support Protobuf payloads. | |||
func (ctx Context) WithLedgerHasProtobuf(val bool) Context { |
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.
@austinchandra Just to understand the context of this PR: Is Evmos creating a custom ledger app just for Evmos?
The SDK team is working on SIGN_MODE_TEXTUAL, which improves ledger signing in general, and comes with a Cosmos-wide Ledger app. https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-050-sign-mode-textual.md
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.
Evmos plans to create a custom Ledger app in the future, which will probably attempt to integrate some variant of SIGN_MODE_TEXTUAL. For now, we are using the Ethereum app to sign Cosmos payloads using EIP-712 Typed Messages, which this PR helps to enable.
Description
Increase customized signing capabilities for Ledger by:
By increasing the degree to which higher-level chains can customize Ledger usage and signing, the Cosmos SDK can become better-suited to serve chains that differ from the default; this can include EVM-based chains that do not use the Cosmos Ledger app, or Cosmos-based chains with their own Ledger implementation.
PR
This PR introduces the ability to customize Ledger support for apps with secp256k1 ECDSA keys, such as Ethereum and Cosmos. Key changes and relevant files:
Options
type within Ledger to track customizationsLedgerHasProtobuf
field toContext
to indicate whether the Ledger instance can support ProtobufSignDocs
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change