Hacker News Reader

Comment by mpyne | Hacker News Reader

Another trick I've used is to use named FIFOs for commands that expect there to be files rather than stdin/stdout. The command that spits the sensitive credential outputs to the FIFO and blocks.

The command that needs the sensitive credential to be input is pointed to the FIFO and reads it, and nothing is left over on disk or in the shell's history or memory.

View on HN

Process substitution (the `<(echo ...)` approach I used in the post) is practically equivalent to this, creating a path that can be read by the shell and its child processes (and, at least as expanded, _only_ by them) just like a named FIFO -- but without the race condition mentioned by SoftTalker.

What you've hinted at and what I didn't mention in the post is that this is indeed a good way to avoid even having the secret ever be a shell variable. It's a bit of extra fiddling to turn just the token into the Authorization header, but it's certainly possible, something like this:

curl -H @<(rbw get gitlab-access-token | sed 's/^/Authorization: Bearer/') https://gitlab.example.com/api/v4/projects

I was going to mention this too, it was a pretty common approach we used in batch files. There's a potential race condition if something else can read from the fifo after the secret is there but before the intended process consumes it, so you still need to be careful with permissions.

would very much like to see a small example of how to create, consume, and destroy those FIFOs...

https://man7.org/linux/man-pages/man1/mkfifo.1.html

Pretty simple. This creates a named pipe. One end of a shell command redirects to it, one end redirects from it. rm when finished.

You can just use process substitution

cat <(secret-print my-secret)

In a shell script situation, you'd typically trap EXIT and ERR and remove the fifo in the handler.

Reply on news.ycombinator.com