-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Ledger hardware wallet integration #8068
Conversation
@garious , I haven't yet found a unique identifier for the Ledger without querying the device. Each device does report a serial number, but both the Ledgers I currently have report the same number ("0001"), so I'm guessing that's not being set in manufacturing. |
I don't like the $ solana set --keypair usb://<name>
$ solana-keygen pubkey
E13eqyhs8uJvXtKfmTkt82tiEk1hbz3R2E7GgbMtEYBH And also, that extra output should only be there if the user passes a Regarding that syntax:
That's neat, but how about an option instead, |
Yes, I plan to implement something in the solana-cli config, as noted in the pr description. However, currently solana-keygen does not use/read the solana-cli config. This is a similar issue to that noted here: #7304. The CLI config is just for the cli. It is easy enough to have solana-keygen read that file. Is it enough that solana-cli is the only module that sets it?
Sure
Do you think the explicit |
@garious There is precedent for |
I like |
Regarding the argument or option, I think optional things should use options. I don't like the idea of modes, where if the keypair points to a USB, you're in "2 argument" mode. There's a reasonable default path, 0. |
d7d5ac0
to
cd4f39a
Compare
@garious , I think this is quite a bit closer. Current flow:
If the remote-wallet path (set in config or passed explicitly) matches more than one device (eg. |
c2f9eee
to
d650cac
Compare
Here's example output from the solana-cli implementation:
|
Is that a derivation path at the end of the keypair URI? |
Un that example, what is the out of |
Yes. Perhaps it should be stored in a different config setting(?), but it definitely seems useful to be able to set the specific pubkey for a whole batch of actions. Like
Currently:
|
45c6f43
to
d650cac
Compare
Sounds good to have the derivation path. Just make sure there's lots of unit tests. Things get super weird because a missing
The awkward ones is the difference between #1 and #3. If a file path, then no derivation path means that you want the public key for the keypair in that file. If a USB path, then no derivation path means you want the public key at a default derivation path "0". In any case, most important is that given the same seed phrase, #2 and #4 result in the same public key. |
Regarding the verbose output, too many inconsistencies between |
Fair! Predates this pr, so I'll fix separately and rebase. |
d650cac
to
88dc91e
Compare
|
||
pub(crate) fn pubkey(&self) -> Result<Pubkey, Box<dyn std::error::Error>> { | ||
if let Some(path) = &self.keypair_path { | ||
if path.starts_with("usb://") { |
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 expression is repeated a bunch of times and written as those USB is the one special case. If other protocols are added, the filepath will be the syntactic special case. Better would be to:
match parse_keypair_path()? {
KeypairUrl::Filepath(keypair_path) => ...,
KeypairUrl::Usb(stuff_after_usb_colon_slash_slash) => ...,
}
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 is a great suggestion. However, I think it is closely related to the CLI refactor that needs to happen to handle various types of signers (present and not), so I'd like to handle it as part of that work.
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.
sounds good
88dc91e
to
39c9959
Compare
39c9959
to
e06f755
Compare
e06f755
to
8e31707
Compare
Codecov Report
@@ Coverage Diff @@
## master #8068 +/- ##
========================================
- Coverage 81.8% 81.4% -0.5%
========================================
Files 248 250 +2
Lines 53533 53988 +455
========================================
+ Hits 43833 43980 +147
- Misses 9700 10008 +308 |
* Initial remote wallet module * Add clap derivation tooling * Add remote-wallet path apis * Implement remote-wallet in solana-keygen * Implement remote-wallet in cli for read-only pubkey usage * Linux: Use udev backend; add udev rules tool * Ignore Ledger live test * Cli api adjustments (cherry picked from commit ed0c1d3) # Conflicts: # Cargo.lock # clap-utils/Cargo.toml # cli/Cargo.toml # keygen/Cargo.toml
* Initial remote wallet module * Add clap derivation tooling * Add remote-wallet path apis * Implement remote-wallet in solana-keygen * Implement remote-wallet in cli for read-only pubkey usage * Linux: Use udev backend; add udev rules tool * Ignore Ledger live test * Cli api adjustments (cherry picked from commit ed0c1d3)
Problem
Solana users need to be able to manage their keys securely. In particular, they need a secure way to generate keys for genesis accounts. Enter hardware wallets.
Ledger app development is in progress (https://github.com/solana-labs/ledger-app-solana). This work is an initial implementation of CLI and keygen client integration.
Summary of Changes
pubkey
subcommand. Enables selection between multiple wallets. Hardware wallet use examples:Work Remaining
Integrate into solana-cli:
solana
cli:address
,airdrop
,balance
,create-address-with-seed
Other: