Add option to define environment vars

[jsgf]

Right now, code can use env!() and option_env!() to query arbitrary environment variables set at the time rustc is invoked. This is a subtle leak of the compilation environment into the generated code, which can cause issues with build reproducibility, and could conceivably be considered a security problem.

I'd like to have the option to completely define the "environment" that's available to env!() on the compiler command line to an explicitly delimited set of names and values

For example:

--override-env - disable querying of real environment --set-env name=val - define an environment variable (added to existing env if --override-env not set) --unset-env name - make a name unset

cc @luser - this seems pertinent to caching https://github.com/rust-lang/cargo/issues/3066

[jsgf]

Also relevent: https://github.com/rust-lang/rust-roadmap/issues/12

[Mark-Simulacrum]

This is a feature request to override the environment available at build-time. I'm wondering if build scripts could help here -- perhaps they could clear the environment? I worry though that wouldn't affect dependencies, presumably.

[jsgf]

I don't think a build script would work, because that would imply that the build script is invoking rustc rather than cargo itself. (It also doesn't cope with the case of setting the env for the build script itself).

An alternative is that cargo could override the environment before invoking rustc, but it's not possible to override the entire environment so long as the build process itself needs some environment set (HOME, CARGO_HOME, PATH, LD_LIBRARY_PATH, etc).

There's are two distinct (but related) issues here:

• precisely controlling the environment for build reproducibility
• preventing somewhat untrusted code from external sources from "sniffing" the environment (which is exacerbated by also allowing unconstrained file-inclusion).

In practice, these amount to the same problem (Rust code has unconstrained access to the environment, which forms undeclared dependencies), and can be controlled in the same way (only allow the rust compilation environment access to a completely "synthetic" environment).

[steveklabnik]

Triage: this feels like a big enough thing that it maybe is RFC-worthy; regardless, it's not clear to me what team to assign this to.

[Mark-Simulacrum]

I tend to agree that an RFC would be necessary here, though perhaps a small one. We could also plausibly start by adding -Z flags to rustc that allow precisely controlling what include!, include_str! and env! can see (probably not rising to sandbox-level control, but something like enumerating the list of environment variables and files seems not too hard, given usage of e.g. same-file.

[jsgf]

I had an RFC underway but as I implemented it I realized it didn't really work the way I wanted it to. I need to get back to it.