That was a hard to read font.
I'm surprised you say that. Iosevka is quite beloved as a monospace font. I use it for all my terminals, etc.
Environment variables are a legacy mess: Let's dive deep into them
101–110 of 194 posts
Re: Environment variables are a legacy mess: Let's dive deep into them
#102Earlier quoted context omitted.
Linux's namespaces are not a security mechanism. Please do not use them as one.
Is there consensus around that? Given how containers and bubblewrap/flatpak are considered (to some degree) security boundaries, I approach statements like this with skepticism.
You answered your own question. Bubblewrap uses namespaces, but not by themselves. They're used in conjunction with other tools to provide a security boundary. Even then, it's not a very good security boundary. A serious security boundary should hold up even to privilege escalation, which is not true for bubblewrap.
Re: Environment variables are a legacy mess: Let's dive deep into them
#103Earlier quoted context omitted.
You have a config file, it needs to have secrets so likely you are going to run some templating system where you replace dbpassword: ${dbPassword} with password from some secret system. Hopefuly you understand possible issues with any templating system that could result in replacement failures. String manipulating is one of those "This is easy" until it's not.
Apparently I'm still unclear. I don't mean to hardcode secrets into the config file either. I was suggesting to put a command into the configuration file that the application then calls to get the secret. This way the secret is only ever passed over a file descriptor between two processes.
I do something similar. I usually have a flag, something like --password-file. It can only be used to specify a file containing the secret and at startup the application reads it.
Re: Environment variables are a legacy mess: Let's dive deep into them
#104Earlier quoted context omitted.
You can have a command setting that is invoked to get the string. This way you don't have vendor login, but also don't need a separate template step.
You still need to present that to Application. So Command Line leaks worse than Env Var. Config file, see original post for problems. Env Var, see blog for problems.
I think parent is referring to something like SOPS [0], which can pass secrets via FIFO. That way, there’s nothing on disk, the pipe is cleared after first read, and /proc/cmdline doesn’t reveal anything.
Re: Environment variables are a legacy mess: Let's dive deep into them
#105Earlier quoted context omitted.
Why are they the right tool for that instead of passing data with program args or another way of IPC?
Program args can be seen with tools like 'ps', so passing credentials that way is a poor choice.
Well yeah of course. What you could do though would be to have e.g. --secrets-file and at startup time the application reads that file to get the secret. Then you could use file permissions to make sure only the (application) user running the application can read that file (or even more extreme, the application destroys the file after reading it).
I think that would still be better than env vars, which are more likely to leak somewhere you didn't intend them to.
Re: Environment variables are a legacy mess: Let's dive deep into them
#106To give an illustration of how bad this can get: At a past firm, I was trying to debug how a particular ENV var was getting set. I started out thinking it was something simple like the user's .bashrc or equivalent. I quickly realized that there were roughly 10 "layers" of env var loadings happening where the first couple layers were: - firm wide - region - business unit - department - team etc etc I ended up having t…
Not sure if any other high level languages have it, but Node.js has just added command line flags to trace precisely all env var accesses and modifications:
https://nodejs.org/api/cli.html#--trace-env
Since you can set/unset/modify env vars in so many ways with different APIs, this sounds super useful in complex debugging scenarios.
Re: Environment variables are a legacy mess: Let's dive deep into them
#107I get anxiety whenever I need to set an environment var on Linux. There are (somewhat distro-specific) ways that work properly, but the usual procedures you find online stops working once you reboot (or close the terminal I think?). They should add a simple env var GUI like Windows has that just works , and isn't terminal-specific. Windows has the annoyance of needing to restart the the terminal (or open a new one) f…
> but the usual procedures you find online stops working once you reboot (or close the terminal I think?) The environment isn't persistent between sessions. That means you need to make the change in a way that runs on every new session (login or new terminal window). Depending on how your system is configured: .bash_profile gets run once on every login .bashrc gets run once on every non-login new session (i.e. a new…
That applies if you use bash. If you use another shell, you'll need to use that shell's methods to set environment variables in the config(s). And probably still need to set them for bash so that bash scripts get the correct env vars.
NixOS & home-manager do have functions that can set environment variables across all shells enabled via either of those systems. So I've got `programs.bash.enable = true;` && `programs.fish.enable = true;` && `home.sessionVariables = { EDITOR = "nvim"; };` in my home-manager config for example. A GUI editor for that would certainly be possible.
Re: Environment variables are a legacy mess: Let's dive deep into them
#108Environment variables also suck due to having zero typo existence. Write FOO_BAR instead of FOO_BARS? Silent failure. V1 of your package recognizes FOO_BAR and V2 changes it to FOO_BARS (because now we can have more than one)? Silent failure.
In a shell script, set -u. It’ll terminate if you reference an unset variable.
In other languages, check that the var you pulled in isn’t falsey before proceeding.
Re: Environment variables are a legacy mess: Let's dive deep into them
#109Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…
> Any good solutions for passing secrets around that don't involve environment variables or regular plain text files?
Plain text files are fine, it's the permissions on that file that is a problem.
The best way is to be in control of the source to the program you want to run then you can make a change to always protect against leaking secrets by starting the program as a user that can read the secrets field. After startup the program reads the whole file and immediately drops privileges by switching to a user that cannot read the secrets file.
Works for more than just secrets too.
Re: Environment variables are a legacy mess: Let's dive deep into them
#110[deleted]