keepassxc-cli usability improvements

[stdedos]

Summary

For the simple case of:

u@h:~$ keepassxc-cli show --attributes Password db.kdbx 'entry with spaces'
Enter password to unlock db.kdbx: 
PROTECTED

Desired Behavior

1. Allow attributes to be resolved case-insensitively

u@h:~$ keepassxc-cli show --attributes password db.kdbx 'entry with spaces'
Enter password to unlock db.kdbx: 
ERROR: unknown attribute password.

2. In this command, where entry is the last field, concatenate the rest of $@, so as to not need to remember to escape spaces (e.g. with quotes)

u@h:~$ keepassxc-cli show --attributes password db.kdbx entry with spaces
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>          Yubikey slot used to encrypt the database.
  -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.
  -h, --help                    Display this help.

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

3. Glob-match unique entry. If my entries are: entry with spaces, foo, bar, then this would work

keepassxc-cli show --attributes Password db.kdbx entry
Enter password to unlock db.kdbx: 
Could not find entry with path entry.

Somehow this was never added??

4. Separate information and data streams
   One reason for using the CLI would be that, somehow, a program requiring a password could be taught to use keepassxc-cli to obtain it without storing sensitive information in plaintext. I am not an expert, and I cannot argue with the validity / security of the current design / my solution proposal; however, currently, this user case is complicated:

# No one said all examples can make a lot of sense :-D
u@h:~$ bery-sekur-program-wants-pass-stdin <(keepassxc-cli show --attributes Password db.kdbx 'entry with spaces')

What happens from here on, is complicated for two reasons:

1. The password prompt comes on stdout. But that's already forwarded; so nothing to see here
   In the normal case, not echoing typed characters is okay. With the additional issue of keepassxc not producing any output, this will only confuse an unexpecting user.
2. After "figuring out" [1], the user might wonder why is his password wrong.

My proposal here is:

1. Send the prompt stream (and a possible "db password error") on stderr and the password, and only the password, on stdout, or
2. "If you can write to /dev/tty", then send all output there, and password-only to stdout.

Assuming that keepassxc-cli show is the API some program would bind to ask for information, including passwords, then IMHO stdout should be "reserved" for that communication. If that means you would output non-error information on stderr (which, I cannot think of besides the db unlock password prompt), I think it's a contract worth breaking for this case.

Possible Solution

Context

CLI tools from GUI should be done as ... CLI-ly as possible. While, it is true, for 3, I could do e.g. keepassxc-cli locate followed by keepassxc-cli show, it might be more user-friendly to just give me hints, and take hints yourself (i.e. the cli) too

[sjamesr]

#3947 should address your first issue.

The second issue is something I've wanted too, maybe I could take a look at doing that.

I like the third idea, I'll look at that too.

[droidmonkey]

I can toss a bounty on this one to support your efforts.

[stdedos]

It seems that the Internet ate one of my bulleted points ([4]).

I added that again on the description.

[droidmonkey]

I do not agree with implementing feature 2, using escaped spaces or quotes is standard in command line.

Feature 3 should allow for wildcard support: keepassxc-cli show --attributes Password db.kdbx entry*. Implicit wildcards produces undefined results that are not desirable for people who expect exact matches.

[timka]

@stdedos Not sure if I understand your 4th case correctly, but why not write a wrapper to have your CLI instance running in 'open' mode as a daemon? Once started that wrapper handles CLI's std{in,out} and exposes whatever interface to the rest of your environment. For instance, a UNIX socket for communicating with the wrapper and a CLI tool. Very much like ssh-agent.

BTW, with this approach 2nd feature could be nicely implemented using programmable shell completion. Which is of course the proper way of doing this. Also as completing entries' names would be possible you wouldn't need globbing while using your CLI tool interactively.

The downside of this approach is that for security you'd have to implement database locking on timeout and other events like the GUI version does.

[stdedos]

@stdedos Not sure if I understand your 4th case correctly, but why not write a wrapper to have your CLI instance running in 'open' mode as a daemon? Once started that wrapper handles CLI's std{in,out} and exposes whatever interface to the rest of your environment. For instance, a UNIX socket for communicating with the wrapper and a CLI tool. Very much like ssh-agent.

Well, yes, technically I could do it.

However, from my side, that means parsing text, and seeing all the possible problems and deciding which is which.
From keepassxc's side, it means carefully designing the (specific) interaction / use case.

BTW, with this approach 2nd feature could be nicely implemented using programmable shell completion. Which is of course the proper way of doing this. Also as completing entries' names would be possible you wouldn't need globbing while using your CLI tool interactively.

I am not sure if you have written CLI completion scripts. Again, it is more complicated to solve externally, than internally.

The downside of this approach is that for security you'd have to implement database locking on timeout and other events like the GUI version does.

... and something else I clearly have not thought / cared about.

[timka]

@stdedos Not sure if I understand your 4th case correctly, but why not write a wrapper to have your CLI instance running in 'open' mode as a daemon? Once started that wrapper handles CLI's std{in,out} and exposes whatever interface to the rest of your environment. For instance, a UNIX socket for communicating with the wrapper and a CLI tool. Very much like ssh-agent.

Well, yes, technically I could do it.

However, from my side, that means parsing text, and seeing all the possible problems and deciding which is which.
From keepassxc's side, it means carefully designing the (specific) interaction / use case.

It's not that hard. You just reprint whatever comes out of keepassxc-cli's stderr. There's no way you can handle an error anyway. You just tell about it and break.

BTW, with this approach 2nd feature could be nicely implemented using programmable shell completion. Which is of course the proper way of doing this. Also as completing entries' names would be possible you wouldn't need globbing while using your CLI tool interactively.

I am not sure if you have written CLI completion scripts. Again, it is more complicated to solve externally, than internally.

Depends on the shell. For instance, fish is not that hard. Anyway, that's how things supposed to work by design. No one actually expects a CLI program to behave the way you suggest. And I don't think working in a shell productively is possible without completion for the tools one uses frequently.

The downside of this approach is that for security you'd have to implement database locking on timeout and other events like the GUI version does.

... and something else I clearly have not thought / cared about.

I agree, that's something I'd appreciate keepassxc-cli having out-of-box. Actually, even having a CLI way to talk to the running GUI app like the browser extension does would be nice. But it's open source and I can't expect someone do this for me so I scratch my own itch.

[stdedos]

Well, yes, technically I could do it.
However, from my side, that means parsing text, and seeing all the possible problems and deciding which is which.
From keepassxc's side, it means carefully designing the (specific) interaction / use case.

It's not that hard. You just reprint whatever comes out of keepassxc-cli's stderr. There's no way you can handle an error anyway. You just tell about it and break.

I think you are missing a point here (to be fair though, I am not explicitly mentioning):

If you do redirection (e.g. the example [4]), then keepassxc's interaction is lost totally. I am guessing I also tried with wrong password, and that was lost too.

Depends on the shell. For instance, fish is not that hard. Anyway, that's how things supposed to work by design. No one actually expects a CLI program to behave the way you suggest. And I don't think working in a shell productively is possible without completion for the tools one uses frequently.

I agree with the general premise (CLI completion is necessary). However, programmable shell completion against a locked library? Or will you cache/leak credential "pathnames"?

I guess we come from different schools of thought. My idea is that, after arg-parsing keepassxc-cli show --attributes Password db.kdbx, implicitly joining the rest of $@ with spaces is not such a problem (and to me even wanted). But then again, I have 0 open-source, widely-used programs.

The downside of this approach is that for security you'd have to implement database locking on timeout and other events like the GUI version does.

... and something else I clearly have not thought / cared about.

I agree, that's something I'd appreciate keepassxc-cli having out-of-box. Actually, even having a CLI way to talk to the running GUI app like the browser extension does would be nice. But it's open source and I can't expect someone do this for me so I scratch my own itch.

Well, I made the itch disappear: I don't use keepassxc. I merely threw the idea to see if it gains traction / serve as a talking point in streamlining CLI experience.

[stdedos]

Feature 3 should allow for wildcard support: keepassxc-cli show --attributes Password db.kdbx entry*. Implicit wildcards produces undefined results that are not desirable for people who expect exact matches.

@droidmonkey my resolution logic was going like that:

• Exactly 1 entry matched? Then return it.
• Exactly 1 entry matched case-insensitively? Then return it.
• Exactly 1 entry matched with *input* (or input*)? Then return it.
• Exactly 1 entry matched case-insensitively with *input* (or input*)? Then return it.
• Return error

I understand the complexity (Implicit wildcards produces undefined results that are not desirable); you can just make it a default-off option.

My argument here goes that "you cannot shell-complete" correct names to provide accurate matches (unless you make a bash-completion script to talk to a GUI-unlocked database somehow), so some flexibility counteracts that limitation.

[timka]

My argument here goes that "you cannot shell-complete" correct names to provide accurate matches (unless you make a bash-completion script to talk to a GUI-unlocked database somehow), so some flexibility counteracts that limitation.

Talking to a running GUI instance (like the browser extension does) is not what keepassxc-cli was designed for. It's purpose is being purely CLI frontend. IMO, what should be done is making CLI act as an agent that you start at login, unlock your database, and then other processes talk to it via UNIX socket, for instance.

This is what I'm trying to implement currently, a Python wrapper that runs CLI in open mode and accepts commands via UNIX socket.

[timka]

My first approach was checking out the browser extension protocol but it looked too complicated.

[stdedos]

There is implementation in Rust https://github.com/Frederick888/git-credential-keepassxc

[timka]

Yes, I mentioned it bellow

[stdedos]

If you have code/artifacts that I could look/use, feel free to link them

[timka]

It's still an early prototype but sure I'll keep you posted

[timka]

https://gitlab.com/teamoor/keeppy

[stdedos]

There is a typo here 😅 https://gitlab.com/teamoor/keeppy/-/blob/master/keeppy/client.py#L80

I have tried to use it - I didn't feel that natural to me.
I may be doing it wrong, however 😕

[timka]

Also apparently there's #4513 and https://github.com/Frederick888/git-credential-keepassxc