Add simple ability to show passwords via CLI

[vaygr]

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 or weechat 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 plain gpg for this: gpg --batch -q --decrypt ~/.config/mutt/master.gpg. Or a password manager like pass: 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.

[firecat53]

Sounds reasonable and likely not too difficult.

[firecat53]

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?

[vaygr]

Second.

I think how keepassxc-cli works is you pass the database and entry and it asks for the password interactively:

$ keepassxc-cli show -h
Missing positional argument(s).

Usage: keepassxc-cli show [options] database entry
Show an entry's information.

Options:
  -q, --quiet                    Silence password prompt and other secondary
                                 outputs.
  -k, --key-file <path>          Key file of the database.
  --no-password                  Deactivate password key for the database.
  -y, --yubikey <slot[:serial]>  Yubikey slot and optional serial used to
                                 access the database (e.g., 1:7370001).
  -t, --totp                     Show the entry's current TOTP.
  -a, --attributes <attribute>   Names of the attributes to show. This option
                                 can be specified more than once, with each
                                 attribute shown one-per-line in the given
                                 order. If no attributes are specified, a
                                 summary of the default attributes is given.
  -s, --show-protected           Show the protected attributes in clear text.
  --all                          Show all the attributes of the entry.
  --show-attachments             Show the attachments of the entry.
  -h, --help                     Display this help.

Arguments:
  database                       Path of the database.
  entry                          Name of the entry to show.

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.

[firecat53]

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?

[vaygr]

Yes, chezmoi would cache the keepass database password. In case of keepassxc-cli I think they use tty.

[firecat53]

Sorry if I'm being dense, but it seems like you're looking for something different than I'm understanding.

I'm thinking: keepmenu --show "Joe's Grill" -d db.kdbx -> Prompts for passphrase on the CLI (not launcher) -> outputs Joe's Grill password to stdout (or to clipboard if the -C flag is passed).

• If the database is not passed and there is more than one db listed in the config->error.
• If the keyfile isn't included in the config file-> error
• If keepmenu is already running and one of the open db names is passed with -d ->outputs password.

I'm not understanding your intended workflow.

[vaygr]

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.

[firecat53]

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.

[firecat53]

Initial working idea on the run_once branch. It doesn't have detection of currently open db's.

[vaygr]

OK, simple cases work, that's great:

$ keepmenu -s "DigiCert"
Password:
changeme

A bit more complex need massaging though:

$ keepmenu -s "Duo"
Password:
Multiple entries found matching 'Duo'. Please be more specific.
  - Hosting/Auth/Duo (user1@domain1.tld)
  - Hosting/Auth/Duo (user2@domain2.tld)

I have a multi-level topology here, so how can I be more specific? keepmenu -s "Duo (user1@domain1.tld)" didn't work, but also..:

We need to be able to distinguish between these two even with the same usernames:

- Hosting/Auth/Duo (user1@domain1.tld)
- Work/Place/Duo (user1@domain1.tld)

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 -s "Hosting/Auth/Duo" didn't work for me either.

[firecat53]

I'm really close now (6 months later 🙄).

• You can enter portions of multiple search terms and it should find the entries (e.g. 'Work Duo' or 'Host Duo user2' both should find the correct entries.
• Add a --no-prompt flag to disable prompting for the db password if desired (e.g. password is provided by password_cmd)
• If the daemon is running, it will use without prompting for a password either the currently active db if -d is not passed, or the db provided by -d.
• If the daemon is not running, password prompting occurs on the command line.

The one remaining issue to solve is that if the daemon is running, the password prompting happens in the GUI instead of the CLI, so you have to run the command twice to return the correct value, as the first run returns from the client run before the db is unlocked.

[firecat53]

@vaygr Is it reasonable to assume if the daemon is already running that we should prompt for the password using the GUI instead of on the CLI? Or if you run with -s should it always prompt on the CLI (if needed)?

[vaygr]

Yeah, I think CLI prompt is important, because that's the only way tools like chezmoi could pass the password.