Add option to define environment vars

2a5613d
Opened by Jeremy Fitzhardinge at 2020-03-30 17:42:56

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

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

    Jeremy Fitzhardinge at 2017-02-08 22:33:44

  2. 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.

    Mark Rousskov at 2017-05-22 16:32:23

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

    Jeremy Fitzhardinge at 2017-05-23 17:36:57

  4. 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.

    Steve Klabnik at 2020-03-28 19:49:08

  5. 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.

    Mark Rousskov at 2020-03-29 15:01:58

  6. 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.

    Jeremy Fitzhardinge at 2020-03-30 17:42:56