If they're gonna work around your "no password via argv" security design, it might be a reasonable thing to jst let them. Anyone who goes:

hide add -n account -u user -p password123

And gets an error message saying "Sorry, you can't put the password into the command,it's a security problem in things like bash_history. Please use STDIN"

Then goes "Fuckit!":

echo 'password123' > hide add -n account -u user -p

Maybe they should be allowed to do that?

(I can almost imagine scenarios where someone might want to use a tool like this in some server automation thing where the security tradesoffs really do make using it like that a not awful idea?)

This is a good point, and I should have been more precise in my original comment :-)

If the program is on a TTY, then reading with echo disabled (i.e., `read -s`) is definitely preferable. I usually have stdin configured as a fallback for when the program isn't on a TTY, for programmatic use.

This has the `echo` problem that you mentioned, but it's strictly better than either argv or the environment (both of which persist throughout the program's lifetime and appear in places like procfs).

For programmatic use a file or system keychain is safer than stdin.

Agreed re: the file.

For the system keychain, I think we're talking about different use cases, no? The system keychain should be used to store the master password, but using it to pre-store any password you intend to later store in another password manager feels a little silly.

An envvar with a fallback of read -s might be the best compromise?

These can be recorded also, the best way is likely a password/key file.

Tip: if you prefix your command by a space in bash (and maybe other shells) that command doesn't get recorded in history.

Don’t go doing this and expecting it’s the default behavior. It’s not. Your bash session must have set, at minimum:

   HISTCONTROL=“ignorespace”

Issue is /proc/$pid/environ if enabled. Envvars are visible just like args. I think there are other ways to recover if on same uid.