solana-keygen - Poor mans keypair encryption

[t-nelson]

Problem

There's no mechanism to encrypt a keypair generated by solana-keygen

Summary of Changes

1. Support reading from stdin in read_keypair
2. Print all non-key text output to stderr in solana-keygen

This allows a poor man's keypair encryption via tools such as gpg without the keypair plaintext ever touching disk.

# Key pair creation
$ solana-keygen new -o - | gpg -c -o key.json.gpg
# Print pubkey
$ gpg -d key.json.gpg | solana-keygen pubkey -

May require $ export GPG_TTY=$(tty) on a Mac. You'll see an error along the lines of Inappropriate ioctl for device.

Caveat

When using gpg, the phase phrase prompt gets spammed by the mnemonic output AND the mnemonic output is cleared when the pass phrase prompt updates. Be sure to copy the mnemonic before entering the passphrase.

[codecov]

Codecov Report

Merging #6259 into master will decrease coverage by 2.2%.
The diff coverage is 78.1%.

@@           Coverage Diff            @@
##           master   #6259     +/-   ##
========================================
- Coverage    73.3%   71.1%   -2.3%     
========================================
  Files         219     219             
  Lines       44022   45403   +1381     
========================================
- Hits        32306   32289     -17     
- Misses      11716   13114   +1398

[t-nelson]

@CriesofCarrots RE the gpg passphrase prompt garbling. I tried tweaking the buffering and even reordering printing of the mnemonic and key json to no success. I believe gpg is tossing up the prompt immediately upon being launched rather than waiting for input plaintext data to show up, which makes sense. However, passing --silent to solana-keygen new suppresses the mnemonic altogether and makes for a nice experience. What do you think about forcing --slient when infile == "-" ? Having the mnemonic is probably counter to the intentions of someone interested in encrypting their keypair anyway.

[CriesofCarrots]

Hmm, on my terminal (iTerm2), the mnemonic phrase and passphrase prompt actually seem to behave properly.

I do still like the recommendation of --silent for outfile== "-", as I agree about the intentions of encryption, but I don't think we should force it. What do you think about adding some expanded comments or a readme with usage examples and recs?

[t-nelson]

Which pinentry does that spawn, the GUI one or curses-based terminal one?

[CriesofCarrots]

Which pinentry does that spawn, the GUI one or curses-based terminal one?

The GUI one. Ah, that's the difference?

[t-nelson]

🙃

[CriesofCarrots]

Thanks. Ugh, gross.
I would, however, still prefer to have the mnemonic option somehow.
We could switch to having silent be the default, and an optional mnemonic arg, for outfile== "-"
Or just handle with docs/recommendations, as I mentioned above. Thoughts?

[t-nelson]

I think documenting that --silent should be used if the encryption application prompts for a passphrase on the command line is probably sufficient. That'll be the smallest change to current behavior. We can tune the defaults towards this use case if users complain.

[CriesofCarrots]

I like this much better!
Just need a little fixup to "recover"

[CriesofCarrots]

This section needs to be rewritten to match your changes in "new"

[t-nelson]

Nice catch! I must've lost that in my, "Oh just let me make history pretty..." rebase

[t-nelson]

864c3b8 oughta do it

[CriesofCarrots]

Thanks!
r+ if CI is happy