cargo run spills additional variables into the environment

[jethrogb]

Today I was debugging an issue where the same code used in two different places was behaving differently. After about an hour of head-desking I found out that this is because I was using cargo run in one of the places and invoking a binary directly in the other place.

On my Ubuntu 16.04 system cargo (f9e5481 2017-03-03) sets/changes the following environment variables:

• CARGO_HOME
• CARGO_MANIFEST_DIR
• CARGO_PKG_AUTHORS
• CARGO_PKG_DESCRIPTION
• CARGO_PKG_HOMEPAGE
• CARGO_PKG_NAME
• CARGO_PKG_VERSION
• CARGO_PKG_VERSION_MAJOR
• CARGO_PKG_VERSION_MINOR
• CARGO_PKG_VERSION_PATCH
• CARGO_PKG_VERSION_PRE
• LD_LIBRARY_PATH
• SSL_CERT_DIR
• SSL_CERT_FILE

Additionally, rustup sets/changes the following variables:

• PATH
• RUST_RECURSION_COUNT
• RUSTUP_HOME
• RUSTUP_TOOLCHAIN

I think most of these are probably OK to set because they are namespaced appropriately or expected to be set by wrappers/build tools. Not so for SSL_CERT_DIR and SSL_CERT_FILE. cargo really has no business messing with my SSL configuration when running build artifacts.

[Mark-Simulacrum]

Could you show us your Cargo.toml/Cargo.lock? The SSL variables are possibly from a crate. I can't find them in Cargo's source code, though I could be missing something.

[jethrogb]

# Cargo.toml
[package]
name = "htest"
version = "0.1.0"
authors = ["Jethro Beekman"]

[dependencies]

# Cargo.lock
[root]
name = "htest"
version = "0.1.0"

// src/main.rs
fn main() {
    for (k,v) in std::env::vars() {
        println!("{}={}",k,v);
    }
}

[Mark-Simulacrum]

Looks like it's possibly a dependency of Cargo. I'm afraid I don't know enough there.

[alexcrichton]

I believe this is a dupe of #2888, so closing in favor of that one.