Don’t use environment variables for configuration • Hacker News Board

Re: Don’t use environment variables for configuration

#161

Post by bayindirh » Thu, Apr 01, 2021, 3:18 PM UTC

q3k wrote: post #123

bayindirh wrote: post #118

Earlier quoted context omitted.

I've further clarified my PoV here [0], but it won't hurt to reiterate. I'd be happy in fact. > I think we might have different backgrounds and considerations as to what counts as 'oldschool'? Most probably. All of the software you mentioned (maybe except Exim4) is actively used in our environments, quite a few of them are in very vanilla configs, and some of them are customized to the point of abuse. However, it's w…

> I've started with a C64, please. :) Personal experience in computing is not what I meant. I only realized that I'm not intimately familiar of the dawn of the UNIX daemon and how their configuration methods changed with time, only the echos of this in daily Linux use. Thus, I realized I was possibly extrapolating and assuming things. > Yes, the tools I've talked about are userspace programs, and are not daemons 99.9…

I'd be absolutely horrified if a service that I use need a specific environment variable set in a particular way to work correctly and it's not well documented. That service would get bonus points for inability to configure that particular option in a configuration file.

I personally would never add environment variables to a program I write which may run as a service.

Oh, Java is calling, hold on... :)

Re: Don’t use environment variables for configuration

#162

Post by hajile » Thu, Apr 01, 2021, 3:22 PM UTC

yrro wrote: post #145

bopbeepboop wrote: post #139

Earlier quoted context omitted.

How do command line arguments or config files solve either problem?

Command line arguments aren't inherited by child processes. Unfortunately they are visible to other users on the system, so they're no good for credentials. Config files (or an abstraction of them such as reading config data from a socket), after parsing, result in some credentials sitting in the memory of the process that needs them. They aren't in the environment block, so a quick and dirty "dump all my environment…

It's also easier to encrypt a config file and provide the decrypt key externally.

Re: Don’t use environment variables for configuration

#163

Post by tantalor » Thu, Apr 01, 2021, 3:22 PM UTC

Somebody never heard of CGI?

Re: Don’t use environment variables for configuration

#164

Post by kevinmgranger » Thu, Apr 01, 2021, 3:23 PM UTC

> For example suppose you run a command line program that has some sort of a persistent state.

`$ SOME_ENVVAR=... some_command `

> Then some time after that you run it again:

`$ some_command `

This is absolutely no different from the following:

> For example suppose you run a command line program that has some sort of a persistent state. `$ some_command --some-arg=value `

> Then some time after that you run it again: `$ some_command `

Re: Don’t use environment variables for configuration

#165

Post by goatcode » Thu, Apr 01, 2021, 3:23 PM UTC

Interesting: I went into reading this thinking in the context of programs. However, reading the replies here has made me realize it wasn't constrained to just that. For programs, there are better alternatives, especially if you're using a deployment pipeline that has things like key-value stores. In general, environment variables are great, especially for things that have access, practically, to not much else, like shells.

Re: Don’t use environment variables for configuration

#166

Post by yrro » Thu, Apr 01, 2021, 3:24 PM UTC

bopbeepboop wrote: post #156

yrro wrote: post #145

Earlier quoted context omitted.

Command line arguments aren't inherited by child processes. Unfortunately they are visible to other users on the system, so they're no good for credentials. Config files (or an abstraction of them such as reading config data from a socket), after parsing, result in some credentials sitting in the memory of the process that needs them. They aren't in the environment block, so a quick and dirty "dump all my environment…

> Unfortunately they are visible to other users on the system, so they're no good for credentials. If you’re concerned about your own software logging credentials, command line arguments are negative in two regards: They’re highly visible when the process is running; they’re often automatically logged. > They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure…

Good point about command line arguments being often automatically logged! So they bad for both reasons :)

Now, if you're running in k8s then you can improve your setup by mounting your secret into your container, and have your code read the credentials from the file within the mount. This just looks like another kind of config file to me :)

Re: Don’t use environment variables for configuration

#167

Post by 0xEFF » Thu, Apr 01, 2021, 3:26 PM UTC

intrepidhero wrote: post #150

yrro wrote: post #131

Earlier quoted context omitted.

Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive'…

Isn't storing credentials in environmental variables bad practice to begin with?

What better place is there to store credentials?

Re: Don’t use environment variables for configuration

#168

Post by junon » Thu, Apr 01, 2021, 3:32 PM UTC

hjek wrote: post #142

junon wrote: post #50

Oh this guy again. This guy created Meson and has a pattern of being 1) Quite toxic and 2) Entirely dogmatic when it comes to software design. He shows no interest in discussing design problems with Meson and asserts his viewpoints as truth and fact, resorting to snide comebacks instead of having thoughtful conversation. Doesn't surprise me he wrote an article like this. Completely misguided and isn't rooted in reali…

Okay, so when you write that this blog author, who made a post arguing how environmental variables are global mutable state, is quite toxic and resorting to snide comebacks instead of having thoughtful conversation, then that is just you engaging in thoughtful conversation about the issue (which is envvars), and not you making a toxic ad-hominem attack at all, right?

Yep.

Re: Don’t use environment variables for configuration

#169

Post by bayindirh » Thu, Apr 01, 2021, 3:32 PM UTC

zabzonk wrote: post #116

bayindirh wrote: post #108

Earlier quoted context omitted.

> Just because something has been used for decades does not make it good. I'm not calling this is good with the persistence of the original author. I tell that it's one of the realities that we have, and instead of burning it with torches, why not build better conventions around it with better attitude and language? Maybe we can try: "Instead of burying all config under environment variables, why not try doing it lik…

> "Instead of burying all config under environment variables, why not try doing it like this?", and slowly build something better, step by step Use named files, that can be version controlled and documented, but are under direct access from the actual program and can be reported as an error if (for example) they are not found.

Actually, this is how I do:

    1. Make the thing completely configurable with a file.
    2. Add an optional switch to select the location of the config file.
    3. Always ship a well commented, sensible config file with the application. Document environment variables there, if any.
    4. If it makes sense, add the ability generate a default config file if it's missing.
    5. Always add a logger, with good debug and error output (Dovecot is my inspiration and role model there).
    6. Document everything in the code, and in the documentation if possible (external documentation is not my strong part yet. I can't write it fast enough).

Re: Don’t use environment variables for configuration

#170

Post by retzkek » Thu, Apr 01, 2021, 3:35 PM UTC

hjek wrote: post #142

junon wrote: post #50

Oh this guy again. This guy created Meson and has a pattern of being 1) Quite toxic and 2) Entirely dogmatic when it comes to software design. He shows no interest in discussing design problems with Meson and asserts his viewpoints as truth and fact, resorting to snide comebacks instead of having thoughtful conversation. Doesn't surprise me he wrote an article like this. Completely misguided and isn't rooted in reali…

Okay, so when you write that this blog author, who made a post arguing how environmental variables are global mutable state, is quite toxic and resorting to snide comebacks instead of having thoughtful conversation, then that is just you engaging in thoughtful conversation about the issue (which is envvars), and not you making a toxic ad-hominem attack at all, right?

GP is just one voice in this discussion, where others have already addressed the substance of the article. Some context and history is valuable.