alt Hacker NewsAnother 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.
Replies
SoftTalker • today at 5:31 AM
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.
luckman212 • today at 4:26 AM
would very much like to see a small example of how to create, consume, and destroy those FIFOs...
➕ show 1 reply
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