5 ms·
Author doesn't know about https://12factor.net https://12factor.net and as another commenter mentioned, probably hasn't deployed something to a 'production' env
by tedk-42 6y ago
Author doesn't know about https://12factor.net https://12factor.net and as another commenter mentioned, probably hasn't deployed something to a 'production' environment (or rather, doesn't know about separation of such environments in the first place).
- mrkeen 6y agoI don't know about https://12factor.net https://12factor.net either. But I was assigned a task last year to remove configuration from environment variables (for security reasons). I deployed my work to 'production'.
- kelnos 6y agoWell, sure, you shouldn't be putting secrets or other sensitive data in environment variables. But garden-variety configuration is fine to put in env vars. Seems like whoever assigned you this task didn't really know what they were doing.
- b0afc375b5 6y agoOops, I've been putting secrets in environment variables since I can remember. Your comment piqued my curiousity on why this is a bad idea. Found this: https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/ https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-... https://security.stackexchange.com/questions/197784/is-it-unsafe-to-use-environmental-variables-for-secret-data https://security.stackexchange.com/questions/197784/is-it-un...
- Cederfjard 6y agoWhat security concerns did that alleviate?
- mrkeen 6y agoAny third party code in our system can just read whatever's in the environment and POST it to some remote server.
- kerny 6y agoAny third party code can just read your credentials file and POST it to remote server.
- mrkeen 6y agoThat's not where the credentials are stored.
- yokaze 6y agoFile permissions allow finer granularity of access control. Environment variables are visible to any user in the system.
- fps_doug 6y agoUnset them after right after evaluation.
- loopz 6y agoNot in any multi-user multi-process OS. You set environment variables in a process (ie. shell/CMD.EXE) and spawn child process (the program) from that parent. The environment variables will only be visible to those two processes.
- c0l0 6y agoLinux disagrees; try strings /proc/*/environ to see for yourself. On Solaris/SunOS, you could use `pargs -e $PID`. And so on. Having separate UIDs to run your processes A and B under shields either one from peeking at the other's environment, though. UNIX DAC is simple and powerful enough for MOST security concerns, I would argue.
- 6y ago
- remram 6y agoLinux is usually configured to not allow processes from another user to read /proc/$pid/environ. At least a production machine should be. Configuration files are resistant to this as you note, but command-line arguments are not (--password=1234 will show up in ps for everyone).
- tdeck 6y agoTo be fair, "configuration" means a somewhat different thing when we're talking about a user application vs a server. It's easy to forget on HN that some software engineers don't write web servers at all. Having used the profiling tool TAU (subtle dig), I instantly understood what the author is driving at, and I somewhat agree for many use cases. I shouldn't have to fill my dotfiles with 10 new variables just to use a utility.
- rolfvandekrol 6y agoIt looks like the author is talking about command line tools that use env vars for things that should be arguments. In the comments on the page he admits that for example key credentials are valid usages for env vars.
- henvic 6y agoWhy the trolling? He has valid points. It doesn't matter whether he knows about this methodology or not. Does everything looks like a nail to you?
- hjek 6y ago> Author [...] probably hasn't deployed something to a 'production' environment I think you're wrong about that. The blog post author is also author of Meson, the build system.