5 ms·
Neophytes take notice. Attention to details like this is what separates truly great programmers from merely good ones. That said, for scripts reusable by others
by bjourne 1y ago
Neophytes take notice. Attention to details like this is what separates truly great programmers from merely good ones. That said, for scripts reusable by others you should use command line arguments . Environment variables in lieu of command line arguments is a huge code smell.
- shakna 1y agoYou don't generally want API keys accidentally recorded into someone's bash history.
- deleted 1y ago[deleted]
- zahlman 1y agoWhat exactly is your threat model, where the attacker can read ~/.bash_history but can't execute (or capture output from) /usr/bin/env?
- pastage 1y agoYou 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.
- zahlman 1y ago> 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?
- dapperdrake 1y agoThreat model: shell scripts
- ftigis 1y agoHow about not accidentally showing tokens and credentials when live screen sharing?
- shakna 1y agoCI and other build systems. Where tokens have been stolen in the past, by users not caring, and a VM not being properly cleaned.
- fc417fc802 1y agoThe 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.
- RadiozRadioz 1y agoFor 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.
- bjourne 1y agoThen how would you SET the API key in the first place? :) The argument doesn't make any sense at all.
- medstrom 1y agoIn some .profile or .envrc or what you'd call such a file, I suppose.
- NoGravitas 1y agoAnd you expect someone will be able to read your bash_history, but not your .profile?
- medstrom 1y agoFair, I wasn't thinking about the details of how someone would lift out the bash history.
- fc417fc802 1y agoUsing 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.
- connorbrinton 1y agoTyper 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/ https://typer.tiangolo.com/tutorial/arguments/envvar/ It's especially nice for secrets. Best of both worlds :)
- bjourne 1y agoNo, 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.
- fc417fc802 1y agoThis 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.
- bjourne 1y agoGood luck storing your private keys in environment variables!