Will need to double check some machines to make sure these two don't bite me:
On Unix systems the environment variables SSL_CERT_FILE and SSL_CERT_DIR can now be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively.
The os/exec package now prevents child processes from being created with any duplicate environment variables. If Cmd.Env contains duplicate environment keys, only the last value in the slice for each duplicate key is used.
I would be super interested if the os/exec change bites you. I've never seen any definition of how programs should handle duplicate environment variables, and there doesn't seem to be consistency in the wild either.
We went with the bash behavior (latest one wins), which also means all the code previously using:
cmd.Env = append(os.Environ(), "KEY=newvalue")
... now actually works reliably. Previously, if KEY=oldvalue was already defined, what you got depended on your luck with the child program. Either old, new, or random.
I wonder if that could cause security issues with setuid binaries. But then, if you make a Go program setuid and it executes other programs, I guess that’s already asking for trouble. I was thinking it might be possible to use duplicate environment variables to confuse the dynamic linker’s dangerous-environment-variable filter, but that filter would only run in the first place if the Go program happened to use dynamic linking; otherwise there’d be no protection at all (unless Go has some built-in knowledge of what variables the dynamic linker cares about). So just don’t do that, I guess…
Yea, I'm thinking about cases similar to HTTP parameter pollution, and what the program expectations are. You'd be right to argue environment variables should not be user controlled. :)
Note that only the os/exec package has this new cleanup logic.
If you really want to do something nasty and intentionally confuse your child processes, the lower-level os.StartProcess and syscall packages are there for you. :)
> On Unix systems the environment variables SSL_CERT_FILE and SSL_CERT_DIR can now be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively.
This will fix so much pain that my team is having right now. I am glad that it finally is available.
It's like the good side of Zeno's Paradox. If you're alive at age X, your expected number of days to live is still significant. For US males, your life expectancy doesn't fall below one year until you're 113.
Agree 100%. JetBrains tooling is fantastic for enforcing consistent style. The little squiggles and red and orange marks compel people to fix their shit, the way spellcheckers do. To the point that I almost want to pay out of my pocket for subscriptions for my coworkers.
