feat(init-wallet-enc): optionally create enc identity file #320
Conversation
str4d
left a comment
str4d
left a comment
There was a problem hiding this comment.
Initial feedback. Depending on how the UX ends up shaping out for configuring the different possible alternative wallet encryption mechanisms (including plugins #252), it may be better to have a dedicated CLI method for each, and remove init-wallet-encryption (instead doing what it does now inside each of the dedicated methods). But we can start by prototyping the combined UX inside init-wallet-encryption.
| let sk = age::x25519::Identity::generate(); | ||
| let pk = sk.to_public(); | ||
|
|
||
| // Q: should we also include timestamp? | ||
| writeln!(out, "# public key: {}", pk).map_err(|e| ErrorKind::Init.context(e))?; | ||
| writeln!(out, "{}", sk.to_string().expose_secret()) | ||
| .map_err(|e| ErrorKind::Init.context(e))?; |
There was a problem hiding this comment.
Instead of this, what I should do is expose the file-generator code from inside rage-keygen somewhere under age::cli_common for reuse. Then it would also benefit from translations.
There was a problem hiding this comment.
tried to tackle this for a bit but gave up - moving the generator (where the localized strings are found) into cli_common means moving those strings over to age/i18n, and adding chrono as a dependency. Is this what you meant?
Exposing instead only the file creation might be an option? But then we don't really gain much at all from doing so.
I've updated the code now without making a PR to rage - maybe it'll help thinking about what to expose upstream.
| .map_err(|e| ErrorKind::Init.context(e))?; | ||
|
|
||
| info!("Encryption identity file created at {}", path.display()); | ||
| info!("Public key: {}", pk); |
There was a problem hiding this comment.
The recipient is irrelevant to Zallet users.
| info!("Public key: {}", pk); |
zallet/src/cli.rs
Outdated
| pub(crate) struct InitWalletEncryptionCmd { | ||
| /// Creates the encryption identity file if it does not already exist. | ||
| #[arg(short)] | ||
| pub(crate) create: bool, |
There was a problem hiding this comment.
Instead of this being a bool, we should take an enum with variants corresponding to both unencrypted (what is currently implemented) and passphrase-encrypted, so we cover both of the currently-documented use cases.
2 participants
Resolves #302
Wanted to open as a suggestion for dealing with #302, and starting a discussion:
Would it not be better to integrate this behavior directly into the initialization command (with a flag), rather than adding a new command? 2 steps rather than 3 is already a big improvement from a product perspective, let alone removing the requirement of having the extra binary.
But this draft PR is just a placeholder to discuss it, just don't want to waste time in a direction that isn't useful. Obviously there would still be a lot to change+improve here.