Rust: Cargo registry paths are leaked in compiled binary

[danielhuang]

When compiling a rust program, and inspecting the resulting binary, I can see paths of the form $HOME/.cargo/registry/... embedded inside.

Steps to reproduce:

1. Create a new cargo project: cargo init --bin
2. Add a dependency to Cargo.toml, for example regex = "1"
3. Add some dummy code that uses this dependency, for example

use regex::Regex;

fn main() {
    Regex::new(r"{").unwrap();
}

1. Run cargo build --release
2. Then run strings target/release/<name> | grep registry to inspect the binary.

Note that the crate and code example is completely arbitrary — the same behavior occurs with any combination of crates.

Software versions:

• rustc 1.45.2 (d3fb005a3 2020-07-31)
• OS: Linux

[the8472]

That's part of the debug/unwind info. You can map it to a different path via #41555 or remove it by stripping the resulting binary.

[danielhuang]

I ran strip on the binary, but the paths appear to remain.

[goncalor]

I was looking at this same problem yesterday. I can confirm stripping (either with strip or with the nightly rustc stripping feature) does not remove the paths.

[goncalor]

I have just found (thanks to folks on IRC) there's a rustc flag that might help. Try to build with:

RUSTFLAGS='--remap-path-prefix foo=bar' cargo build

Reference
https://doc.rust-lang.org/rustc/command-line-arguments.html#--remap-path-prefix-remap-source-names-in-output

[danielhuang]

--remap-path-prefix can mask the paths, but does not completely remove them. Additionally, this feature requires manually specifying the path prefix to use, which makes it more complicated to use.

[raffitz]

There's also this: Remove panic string formatting, but it requires Xargo.

[goncalor]

@danielhuang yes, I'm aware this does not solve the problem entirely and has the problems you mentioned. My comment was more of a workaround to solve part of the problem.

[nagisa]

but does not completely remove them

--remap-path-prefix exists to give users means to achieve reproducibility.

Given that there are quite many ways to eventually have file! and similar macros invoked (including, but not limited to, panic machinery), I'm not exactly sure where the bug is.

Can you elaborate what exactly you expect the behaviour to be?

[danielhuang]

I want to remove all debug-related information from the binary when compiling in release mode.

[NickeZ]

Could someone label this A-reproducibility?