Tell `rustc` wrappers which envs to pass through to allow env sandboxing

[fenollp]

Problem

In the process of creating a $RUSTC_WRAPPER I realize it needs to know which environment variables build scripts and crates read in order to pass them down to my calls to rustc (and not pass other, possibly sensitive, envs).

These envs can be set in config as the rustc-env map cc https://doc.rust-lang.org/cargo/reference/config.html

These are also set when executing build scripts that output cargo::rustc-env=VAR=VALUE directives cc https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-env

Proposed Solution

A simple solution could be for cargo to set an env when calling rustc (or just when calling a $RUSTC_WRAPPER).
This env only needs to contain environment variable names (these are already set in env by cargo).

I propose to set CARGO_BUILD_SETS_ENVS to a list of space-separated env names (or =-separated, both are illegal in var names).

E.g. compiling the crate self_update would set CARGO_BUILD_SETS_ENVS=HOST_PLATFORM TARGET_PLATFORM
cf https://github.com/Shnatsel/current_platform/blob/57c123569e12f55c2111046f97294750f12c467d/src/build.rs

Notes

I propose .._SETS_ENVS as I'd also like .._READS_ENVS for names corresponding to cargo::rerun-if-env-changed=NAME but this feature request requires further exploration on my part and a whole new discussion.

There are probably other information that my $RUSTC_WRAPPER should have access to (e.g. LD_PRELOADed things, ...). Maybe you have opinions, ideas on this. I'm just not done exploring yet.

[fenollp]

Related: #5282

[weihanglo]

Probably relevant:

• Tracking issue for --env-set flag rust#118372
• Environment variable sandboxing rfcs#2794

[weihanglo]

I feel like Cargo should not reinvent --env-set in inself, and should probably just wait for the stabilization of the feature.

[weihanglo]

While --env-set is an approach to fulfill this feature, it might be considered as a breaking change to recursive cargo calls, like what has been described in #14194. This kind of change may need a new edition to make it the default behavior.

[ehuss]

The cargo team took a look at this issue, but we were unclear about exactly what the use case is, or how all the pieces relate to one another. Can you start from a high level to explain what you are trying to accomplish, what kind of sandboxing you are trying to build, what kind of threat models there are, etc? We were also unclear, since things like env! mean that you don't know which environment variables rustc will be reading until after it reads them.