January 13, 2026
Hide yo tokens, hide yo history
Handling secrets (somewhat) securely in shells
Dev tokens keep leaking, commenters dunk on “just use env vars” and drop secret-hiding hacks
TLDR: Putting secrets in shell commands can leak them; the article shows safer tricks like hidden input and temporary files. Commenters split between clever hacks (named FIFOs) and “use real tools” (kernel keyring), while warnings about environment variables and surprise at the read -s trick stole the show.
The shell security PSA sparked a full-on drama about how to keep your API keys from spilling all over your computer like a soap opera secret. The article explains that putting tokens in commands lets other apps peek at them, and offers clever moves like temporary “virtual files” and the “read -s” trick to keep history clean. But the crowd came with hotter tea. One camp flexed DIY stealth with named pipes (a special kind of file that vanishes after use), while another camp shouted use real key management, waving the Linux kernel keyring and keyctl like a mic drop. The “environment variables are safe” crowd? Immediately ratio’d—commenters reminded everyone that env vars can be read by the system, especially by the almighty root.
Nerd flair showed up too: the Rust folks pulled in type-system sorcery, pointing to facet which labels sensitive data so it doesn’t pop up in logs. Meanwhile, a veteran admin confessed they’d never heard of “read -s,” and the thread turned it into a meme: “20 years in Linux, still learning how not to embarrass myself.” Others plugged PuTTY’s -pwfile and the old-school .netrc for batch scripts, triggering a mini turf war between “practical hacks” and “proper hygiene.” The vibe: secrets are slippery, and the community’s got receipts, jokes, and battle-tested fixes to keep them locked down.
Key Points
- •Passing secrets in command-line arguments exposes them via /proc on Linux, allowing tools like ps and pgrep to read them.
- •Using curl with a header file (protected by umask 077) or process substitution avoids putting secrets directly on the command line and prevents disk persistence.
- •Process substitution provides a virtual, read-once file via /dev/fd, reducing leakage through the process table.
- •Shell history can leak secrets; Bash’s HISTCONTROL (ignorespace) helps, and using read -r/-s to assign variables avoids storing the secret in history.
- •Secrets can be sourced from commands (clipboard tools or a CLI password manager like rbw), which is versatile and handles spaces safely.