> 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.
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.
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.
> 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.
It may be marked as Beta, but I've been using https://developer.1password.com/docs/environments/ since October-ish with no issues.
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.
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.