Rust binaries contain path strings that expose system username when using any dependency

[undersquire]

On compiling for release, there should not be literal absolute paths exposing my system username (which on some of my devices is my real name) inside the binaries. I understand maybe its necessary in debug binaries (however I still see no reason to pack these absolute paths in) but they should 100% not be present in a release build.

I have seen many issues reported about this, yet none of them seem to have came to any solution or fix. I have also seen the flag --remap-path-prefix but that doesn't fix the issue. The paths still remain even after using this flag.

Please let me know if there is any current solution for this, or if it is planned to be fixed in a future release.

EDIT: Stripping the binary using strip or even cargo strip tools do not remove the strings either.

How to reproduce:

• Create rust project
• Add any dependency to the project, like rand for example
• Add code to main.rs that uses that crate in any way
• Build for release using cargo build --release
• Then to see how many times your system name appears in the binary, you can either manually search using a hex editor or if on Unix-like system you can probably use strings target/release/BINARY_NAME| grep YOUR_SYSTEM_NAME | wc -l

For me, it says my system name appears 20 times in a debug binary and 3 times in a release binary using the rand crate and nothing else.

This issue does not occur if you have no dependencies.

Meta

rustc --version --verbose:

rustc 1.55.0 (c8dfcfe04 2021-09-06)
binary: rustc
commit-hash: c8dfcfe046a7680554bf4eb612bad840e7631c4b
commit-date: 2021-09-06
host: aarch64-apple-darwin
release: 1.55.0
LLVM version: 12.0.1

[undersquire]

I just discovered that this has to do with dependencies. It only happens if your project is using a crate and you use the crate in code. For example, I created a new project using Nightly build (i tested it with stable aswell) and added the rand crate to Cargo.toml: rand = "0.8.4"

I then wrote this code that uses that crate.

use rand::prelude::*;

fn main() {
    let mut rng = rand::thread_rng();

    println!("{}", rng.next_u64());
}

Compiling with --release shows there are 3 occurrences of my system name.

However in a empty hello world project, there are 0 occurrences.

[m1ten]

I am able to reproduce this issue.

While looking at the binary (both debug and release) under a hex editor, I found /home/<username>/.cargo/registry/src/github.com-1ecc6299db9ec823/rand_chacha-0.3.1/src/guts.rsdescription() is deprecated; use Display.

Using any dependency in the rust code includes the system username (and absolute path) in the binary.

[Urgau]

If I use the mini-main with the rand crate I have these results:

Build command	Number of instances
cargo build	57
cargo build --release	3
RUSTFLAGS="--remap-path-prefix=/home/<username>=/" cargo build --release	0

Using strings target/<mode>/<bin> | grep <username> to list all the reference and strings target/<mode>/<bin> | grep <username> | wc -l to count them.

[undersquire]

Yeah it seems to be overwhelmingly excessive in debug builds but thankfully mostly reduced in release builds (sometimes). On some of my projects it only barely reduces the count with --release. Hopefully they fix this as I see literally no reason for there to be absolute paths included in a release build.

For me, the --remap flag does not affect anything even with the same format you just provided. It still shows there being 3 instances of the path.

[undersquire]

Ok I figured out why the --remap-path-prefix flag doesn't work for me. I realized that you used the prefix /home/<username>, however that is specific to Linux platforms only. For me on my Mac I had to use /Users/<username>, and on windows C:/Users/<username> etc.

So this needs to simply be defaulted by the Rust compiler, either by providing the default path name or just automatically adjusting path prefixes to /.

[ChrisDenton]

--remap-path-prefix does a literal search/replace for the exact prefix you specify. There is also an effort to replace the current working directory as well. Perhaps Cargo itself should have a setting to help with remapping all directories, including Cargo ones.

IIRC, this is unlikely to be made the default because of debugging concerns (even release binaries may need debugging).

[undersquire]

That flag that was merged actually worked really well (-Zremap-cwd-prefix, using nightly). I'm assuming it will be apart of the 2021 edition since it was merged into master branch itself.

I do think cargo should have on option, however I personally think it should be defaulted to / and the cargo option should be used to enable absolute paths instead, but either way it fine if it removes the requirement of passing the rustc flag every time.

[m1ten]

IIRC, this is unlikely to be made the default because of debugging concerns (even release binaries may need debugging).

Why would a release build need to be debugged?

Edit: That's also a privacy concern.

[undersquire]

Yeah I don't really understand what you mean by release builds needing to be debugged. A release build is meant to be the most stripped and optimized build of a program, debug builds exist for debugging. There should really be absolutely no debugging symbols in a release build.

[SkiFire13]

I'm assuming it will be apart of the 2021 edition since it was merged into master branch itself.

The 2021 has nothing to do with features like this. It's just a way to make some small breaking changes needed to implement other features.

I do think cargo should have on option, however I personally think it should be defaulted to / and the cargo option should be used to enable absolute paths instead

To start I think the option should be explicit and made the default only when it has been shown to work well and not introduce regressions. Anyway this requires an RFC and has already been discussed in #40552, in particular see #40552 (comment) and #40552 (comment).

Why would a release build need to be debugged?

If your release build crashes generally you want to be able to get a backtrace, and that requires debugging informations.

[ehuss]

Thanks for the report! Per the discussion above, this is a known issue. RFC #3127 is a proposal towards changing this behavior. Closing as a duplicate of that and #40552.