Local file path strings embedded in binary about min-sized-rust

[lihe07]

I am able to get rid of all path and dependencies information by adding trim-paths = "all" to [profile.release].
Now the official RFC doc mentioned this option.

[ptdecker]

Thank you @johnthagen, I will check these out!

Also, I was looking through the Unstable Book and found these--any thoughts if they are helpful too? On quick look, looks like perhaps the -Ztrim-paths is related to these. I really appreciate you chiming in on this thread. I'll read the links you provided and close with findings if it addresses my issue.

• remap-path-scope
• remap-cwd-prefix

[johnthagen]

This won't help for size, but a short term idea to help avoid leaking your personal information into the binaries would be to build in a container (for Linux builds) or some kind of generic CI system or VM for Windows/macOS such as GitHub Actions.

[polarathene]

For reproduction, there is this example (which began the discussion that led to -Z trim-paths):

[dependencies]
rand = "0.8.0"

use rand::prelude::*;
    
fn main() {
    let r: f64 = rand::thread_rng().gen();
    println!("{}", r);
}

Then with either the mentioned -Z trim-paths or RUSTFLAGS -Z location-detail=none the home user is not present in the strings output:

$ cargo +nightly build --release -Z trim-paths
$ RUSTFLAGS="-Z location-detail=none" cargo +nightly build --release

• I confirmed it did contain my user home path without either of those options (with or without your Cargo.toml release additons).
• I built this reproduction:
  • With a fresh project created via cargo init + applying the above change snippets.
  • With the current nightly for Rust.
  • On Windows WSL2 x86_64 with the x86_64-unknown-linux-gnu target & toolchain.

---

Perhaps you can verify the above, and then try identify what is being done differently for those not to work. Make sure you're not building from any cache which may already have those paths too?

There is also this issue which notes that RUSTFLAGS will apply differently when an explicit --target is set. I could be misunderstanding that though, may only be relevant when using -C target-feature to override a target default. Still it highlights a gotcha where config compiled differently (the fix for the user was to provide the explicit --target).

TL;DR

Maybe try -Z location-detail=none (RUSTFLAG env, not cargo option), since it seems to achieve the same? (at least in the reproduction example, I assume it's a more aggressive approach with other side-effects)

[johnthagen]

You may be interested in this:

• rust-lang/rfcs#3127 (comment)

Specifically -Ztrim-paths

• rust-lang/cargo#12625

[ptdecker]

Ran with -Ztrim-paths on current nightly but the local paths are still in there. I'm probably doing something wrong with it and will keep working at it.

[johnthagen]

From https://rust-lang.github.io/rfcs/3127-trim-paths.html#cargo:

It is defaulted to none for debug profiles, and object for release profiles

The default release profile setting (object) sanitises only the paths in emitted executable or library files. It always affects paths from macros such as panic messages, and in debug information only if they will be embedded together with the binary (the default on platforms with ELF binaries, such as Linux and windows-gnu), but will not touch them if they are in separate files (the default on Windows MSVC and macOS). But the paths to these separate files are sanitised.

Reading the docs, it seems like this default for release profile should resolve most practical issues related to privacy. So when this goes stable, trimming paths should just work for everyone. Also seems like if you are using nightly, you can already get this behavior by default.

For reference, as of Rust 1.75.0, this is still a nightly-only feature.