4 ms·
You don't generally want API keys accidentally recorded into someone's bash history.
by shakna 1y ago
You 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.