Builds not reproducible because full path to the source code is in the panic and debug strings

[david-a-wheeler]

Hi, currently Rust builds are not reproducible, at least in part because the full path to the source code is recorded in the produced executable (such as in the panic and debug strings). Could this be fixed so that builds can be much more easily reproduced on other computers?

Here's the background. One of Rust's general advantages is countering bugs that can lead to security vulnerabilities. However, for security it's very valuable to be able to have reproducible builds. With reproducible builds, others can verify that rebuilding on a different computer with the same tools will produce the same result, countering subverted and malicious builds. This is not an idle concern; the attack on SolarWinds Orion, which got a lot of press, was due to a subverted build environment.

Rust: A Critical Retrospective has nice things to say about Rust, but it also notes some current problems with its implementation. One of the problems with Rust it reports is that "builds are not reproducible between different computers... I think this is primarily because Rust pulls in the full path to the source code as part of the panic and debug strings that are built into the binary."

This problem is easily verified. E.g., I used this code in `src/main.rs``:

fn demo() {
}
fn main() {
    println!("Hello, cruel world!");
    demo();
}

... and on MacOS ran:

cargo build --release
strings target/release/hello_cargo | grep /Users

Note: On MacOS, "/Users" is equivalent to "/home" on most Linux/Unix systems.

I expected an empty result (no lines produced), because full paths (such as /User, /usr/, /home, /bin, etc.) shouldn't be in the generated executable.

Instead of the expected empty list, I received this long list:

/rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/vec.rs/rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/slice.rs/Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/gimli-0.22.0/src/read/line.rs
/Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/addr2line-0.13.0/src/lib.rsAccessError
 right: ``/Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/gimli-0.22.0/src/read/abbrev.rs()/rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/str/pattern.rscalled `Option::unwrap()` on a `None` valuecalled `Result::unwrap()` on an `Err` value_ZN/Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-demangle-0.1.16/src/legacy.rsZN::_$.SP@BP*RF&LT<GT>LP(RP)C,_R/Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-demangle-0.1.16/src/v0.rsR__Rpunycode{-}..._!f64f32usizeu64u32u16u8isizei64i32i16i8str
'?, > ::{closure:#[] + ; const  unsafe " fn( = : 0x.llvm./Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-demangle-0.1.16/src/lib.rs

This is with rustc --version --verbose:

rustc 1.48.0 (7eac88abb 2020-11-16)
binary: rustc
commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
commit-date: 2020-11-16
host: x86_64-apple-darwin
release: 1.48.0
LLVM version: 11.0

Thank you!

[the8472]

Are you aware of the --remap-path-prefix feature?

[nagisa]

Hi, as mentioned above the --remap-path-prefix solves this problem and has been used to great effect in build systems that rely on reproducibility (Bazel, Nix) to work at all. There are efforts to teach cargo about it here. With that in mind this issue doesn't appear to track anything actionable, so I'll close it.

Thanks for taking time to contribute.

[david-a-wheeler]

Thanks for the reply, and I wasn't aware of --rename-path-prefix. However, that isn't the default, so builds are normally not reproducible.

I think it'd be much better to ensure builds are normally reproducible, not merely to make it possible with special effort.

[the8472]

The RFC linked by nagisa addresses just that.

[david-a-wheeler]

Ah, great! Thank you & good to hear. Thanks for all you do. Take care!