-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add simple ability to show passwords via CLI #150
Comments
Sounds reasonable and likely not too difficult. |
Better late than never :) Started to work on this...are you envisioning that the db needs to be unlocked and operating already in the background or that all the necessary info to unlock the db is passed on the CLI each time or in the config file? |
Second. I think how
That would be most secure. Then, for example, when chezmoi uses it, it would cache the password in plaintext in case of fetching multiple entries before exiting. |
Chezmoi would cache the keepass database password? How is that passed? Or are saying it will cache the chezmoi db password that you retrieve from keepmenu? |
Yes, chezmoi would cache the keepass database password. In case of keepassxc-cli I think they use tty. |
Sorry if I'm being dense, but it seems like you're looking for something different than I'm understanding. I'm thinking:
I'm not understanding your intended workflow. |
Yes, what you've described is exactly how I see it. Above I showed how keepassxc-cli integrates with chezmoi, so when this functionality is implemented in keepmenu, we could implement/ask about chezmoi integration, so keepmenu could be used in chezmoi templating system to fetch passwords/attachments. |
Ah, ok 😄 Thanks for the clarification! I'm almost done, although I still have to see how complex it will be to detect the already open databases. |
Initial working idea on the |
OK, simple cases work, that's great:
A bit more complex need massaging though:
I have a multi-level topology here, so how can I be more specific? We need to be able to distinguish between these two even with the same usernames:
Lastly, even if I had just one entry in the previous example but need to distinguish between the same entry in a different folder, |
keepmenu can already read keepass databases, so implementation of this should be trivial. We probably don't need to spin up a daemon for this and should forego caching altogether.
Rationale: software like
mutt
orweechat
allow you to specify commands to decrypt data that can be used for passphrase purposes (SMTP/POP3/IMAP/IRC auth, certificate decryption, etc.). Typically you would use plaingpg
for this:gpg --batch -q --decrypt ~/.config/mutt/master.gpg
. Or a password manager likepass
:pass show weechat/passphrase
. This forces to either use another password manager or different encrypted files, which promotes secret sprawl.Furthermore, solving this will unlock usage in software like chezmoi for secret retrieval: https://www.chezmoi.io/reference/templates/secret-functions/secret/. Maybe it'll deserve its own function for chezmoi in the future.
This way all secrets can be kept in one database and retrieved by the same tool.
The proposal is to add
-s
/--show
"mode" with an argument to display a password entry at the specified path. This can be extended to other fields, but I think just the password entry could be a good start.The text was updated successfully, but these errors were encountered: