[bradfitz]

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.

File a bug if you see a regression.

[comex]

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…

[Shamiq]

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. :)

[bradfitz]

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. :)