You're not wrong. My gripes above aren't a tacit accusation everyone is slacking off on security. I just wish we had standardized on better tools than env variables to make secrets a little more secure by default without requiring complicated stuff. But life goes on, most locks are more pickable than they should be, etc.

I do quibble with the statement that

> unsetenv(3) is probably enough to avoid the actual attack vector

It's not, because it doesn't modify the environment block of the process. Even if you use unsetenv, you're one path-traversal vuln away from folks being able to read all your startup-time secrets out of /proc/self/environ. Similar is true for exploits that can read process memory in small chunks: it takes time and risks detection to e.g. crawl around the stack/heap of who-knows-what-language to find interesting variables, but it's a lot easier to grab whatever's at the top of the stack by address (the env blob, which I think is also unmodified by most unsetenv(3) implementations). Path traversals and small-arbitrary-read exploits aren't exactly uncommon, and environment variables are the wp-admin/admin.php of exploit targets.

That's a quibble; you're broadly right, and that risk's not nearly severe enough to torture your code or bring in caching + encrypting runtime secret stores or whatnot.

I just wish env had been implemented without a /proc view and with reads requiring a cheap syscall rather than memory-residence, you know? Yeah, it's pointless to speculate about, but still seems like an obviously-preferable-in-retrospect road not taken.

"saffron-grade security" is pretty good, too.