> They sit on disk as plaintext, readable by any process running as your user
The proposed solution:
> Instead of loading secrets from a file, you use a wrapper script that fetches secrets from a secure store and injects them as environment variables into your process
Now they sit "on disk" as plaintext, in /proc/self/environ, still readable by any process running as your user.
That’s why I prefer programs that read all configuration from a file: this file can be dumped with fresh secrete value, read by the program and deleted right away once consumed.
Thanks for mentioning this, a coworker also pointed me to that feature after reading my post. I've since updated the top of the post with two things that stood out to me in the feedback here and on lobste.rs
Nice. One more benefit of this is when using LLM tools like Claude Code or Codex to do something and run tests on a worktree, this solution would work seamlessly.
> They sit on disk as plaintext, readable by any process running as your user
The proposed solution:
> Instead of loading secrets from a file, you use a wrapper script that fetches secrets from a secure store and injects them as environment variables into your process
Now they sit "on disk" as plaintext, in /proc/self/environ, still readable by any process running as your user.
Exactly.
That’s why I prefer programs that read all configuration from a file: this file can be dumped with fresh secrete value, read by the program and deleted right away once consumed.
Environment variables tend to be messy IMO
You will probably really like https://varlock.dev
It’s a whole toolkit for this - with built in validation, type safety, and extra protection for sensitive secrets.
It may be marked as Beta, but I've been using https://developer.1password.com/docs/environments/ since October-ish with no issues.
Thanks for mentioning this, a coworker also pointed me to that feature after reading my post. I've since updated the top of the post with two things that stood out to me in the feedback here and on lobste.rs
I'm pretty sure this uses FIFO under the hood, that's a smart idea !
Mfw typing the command stores the password in plaintext in my shell history
Prefix your entire command with a space, usually prevents saving it to the history file.
Usually I do ^ while setting it as a variable, then I can still save the regular command to the history without the secret.
So the solution is to use a proprietary password manager instead? No thanks
This is a MUCH better solution https://wiki.archlinux.org/title/Systemd-creds
People still code on their local boxes? op is not biometric secured over an ssh tunnel
2 hour train ride with flaky internet. Yes we do.
Another solution integrated with most Linux systems: https://systemd.io/CREDENTIALS/
Nice. One more benefit of this is when using LLM tools like Claude Code or Codex to do something and run tests on a worktree, this solution would work seamlessly.