> 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.
theozero|2 days ago
It’s a whole toolkit for this - with built in validation, type safety, and extra protection for sensitive secrets.
sudahtigabulan|2 days ago
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.
jiehong|2 days ago
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
prognostikos|2 days ago
hollow-moe|2 days ago
jonmagic|1 day ago
unknown|2 days ago
[deleted]
unknown|2 days ago
[deleted]
mahaekoh|2 days ago
embedding-shape|2 days ago
Usually I do ^ while setting it as a variable, then I can still save the regular command to the history without the secret.
theden|2 days ago
ray_v|2 days ago
hebetude|2 days ago
hyperman1|2 days ago
zaik|2 days ago
bibstha|2 days ago