> Unfortunately you're using a browser (or client library) that my anti-crawler precautions consider suspicious because it's sending inconsistent values for Sec-CH-UA-* HTTP request headers...

The world doesn't exclusively use Chrome. Nice to see even the nerds are contributing to the closed web.

I haven't actually tested this, but aren't the input and output handles exposed on /proc/? What's stopping another process from seeing everything?

I used to do that, I had a sort of IDE that launched a local server, bound to localhost.

The launching process would send a random password through stdin to the child after launch, and the child would use that to authenticate the further RPC calls.

It's surprisingly hard to intercept a process' stdin stream.

Interesting approach. I like Docker/Kubernetes way of secret mounts where you can limit user/group permissions too.

Meanwhile, I was an avid user of the echo secret | ssh consume approach, specifically for the kerberos authentication.

In my workflow, I saved the kerberos password to the macOS keychain, where kinit --use-keychain authenticated me seamlessly. However this wasn't the case for remote machines.

Therefore, I have implemented a quick script that is essentially

    security find-generic-password -a "kerberos" -s "kerberos-password" -w | ssh user@host kinit user@REALM

Which served me really good for the last 4~years.

The main practical win is that cmd args show up in `ps aux` for anyone on the system to see, whereas stdin keeps it off that list.

re: the /proc concerns - true, but if someones got same-user access to read your /proc/pid/fd, they can probably ptrace you or read process memory anyway. stdin is more about basic hygiene than stopping sophisticated attackers.

tbh for anything actually sensitive I've been leaning toward tmpfs files with strict perms, or using something like vault/age. stdin is a nice middle ground tho for quick scripts.

linux has a key api that works pretty well

man keyctl

For one of my projects my server needs a private key, and it reads this from a file descriptor on startup and then closes the fd. The fd is set up by the systemd unit, which is also configured to restrict filesystem access for the server. So the server reads a key from a file that is never visible in its mount namespace.