You don't generally want API keys accidentally recorded into someone's bash history.

What exactly is your threat model, where the attacker can read ~/.bash_history but can't execute (or capture output from) /usr/bin/env?

Threat model: shell scripts

You do NOT save passwords in shell history, it is insanely insecure. Lets begin with the passwords being readable by everything that can list tasks.

You can protect passwords in a password manager. You do not need to keep the passwords in env and I do not.

> Lets begin with the passwords being readable by everything that can list tasks.

Why are processes running that can do this, that I don't already fully trust?

> You can protect passwords in a password manager.

What's your plan for supplying the password to the program, given that people will want to automate use of the program?

How about not accidentally showing tokens and credentials when live screen sharing?

CI and other build systems. Where tokens have been stolen in the past, by users not caring, and a VM not being properly cleaned.

The threat model is that history is persistent while the environment isn't. That said, whenever possible you should handle secrets using file descriptors as opposed to environment variables.

For this example, don't just command line arguments. There's an API key there, you don't want an API key visible in your cmdline.

Then how would you SET the API key in the first place? :) The argument doesn't make any sense at all.

In some .profile or .envrc or what you'd call such a file, I suppose.

And you expect someone will be able to read your bash_history, but not your .profile?

Fair, I wasn't thinking about the details of how someone would lift out the bash history.

Using read or an equivalent, presumably. Just because you don't know why a practice is recommended against doesn't mean that there isn't a good alternative.

Typer has a great feature that lets you optionally accept argument and flag values from environment variables by providing the environment variable name:

https://typer.tiangolo.com/tutorial/arguments/envvar/

It's especially nice for secrets. Best of both worlds :)

No, that's an anti-feature. :) Sibling comments here claim that command line arguments "leak" whereas environment variables does not. It's plain wrong. An attacker with access to arbitrary processes' cmdline surely also has access to their environ. Store secrets in files, not in the environment. Now you can easily change secret by pointing the --secret-file parameter to a different file. The only reason people use BLABLA_API_KEY variables is because Heroku or something did it back in the day and everyone cargo-culted this terrible pattern.

One could write a huge treatise on everything that is wrong with environment variables. Avoid them like the plague. They are a huge usability PITA.

This is bad advice. Please don't make claims about security if you're making it up as you go.

Environment variables are substantially more secure than plain text files because they are not persistent. There are utilities for entering secrets into them without leaking them into your shell history.

That said, you generally should not use an environment variable either. You should use a secure temporary file created by your shell and pass the associated file descriptor. Most shells make such functionality available but the details differ (ie there is no fully portable approach AFAIK).

The other situation that sometimes comes up is that you are okay having the secret on disk in plain text but you don't want it inadvertently commited to a repository. In those cases it makes sense to either do as you suggested and have a dedicated file, or alternatively to set an environment variable from ~/.bashrc or similar.

Good luck storing your private keys in environment variables!