Feat/os keychain followup - #1770
Conversation
244508d to
a97ccbb
Compare
072a3af to
e120595
Compare
df3543a to
3311a50
Compare
6a4b0ff to
f263d8d
Compare
c39bf60 to
fe02078
Compare
f4e2913 to
3acc3d0
Compare
willemneal
left a comment
There was a problem hiding this comment.
I still need to try this out locally, but correct me if I'm wrong, but it's possible to have the name used in keys add differ from what is used in entry-name?
Good call! Yeah, at the moment, this is possible. It still ends up working because we are saving the value of Though, this may be confusing. 🤔 Instead, we could remove the But, now I'm starting to wonder if we shouldn't allow users to add keys from the keychain at all. If we do, we'd need to make sure that users add the keys to their secure store with:
And we could probably do that, but I'm not sure how necessary this feature is. 🤔 |
|
Since we are now planning to store the seed phrase instead of the signing key in the OS secure storage, I think that a more useful feature would be to allow a user to add a new key with their seed phrase, which is saved in secure storage instead of in the local file. So the command could look like this: which would then prompt the user to enter their seed phrase: |
- this is the only place it is being used - also, this help with a cyclic dependency i was noticing when trying to use secure_store in secret and generate
|
🎉 |
What
This PR is based on #1703 and adds some additional compatibility with the secure store like
keys rmandkeys add.keys rmkeys addcargo run keys add --secure-store alice(will be prompted for a seed phrase)cargo run keys address alicestello keys rm aliceWhy
I wanted to keep #1703 from getting too big so it was easier to review.
Known limitations
[TODO or N/A]