Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo registry paths are leaked in compiled binary #75799

Closed
danielhuang opened this issue Aug 22, 2020 · 13 comments
Closed

Cargo registry paths are leaked in compiled binary #75799

danielhuang opened this issue Aug 22, 2020 · 13 comments
Labels
C-bug Category: This is a bug.

Comments

@danielhuang
Copy link
Contributor

danielhuang commented Aug 22, 2020

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 (d3fb005 2020-07-31)
  • OS: Linux
@danielhuang danielhuang added the C-bug Category: This is a bug. label Aug 22, 2020
@the8472
Copy link
Member

the8472 commented Aug 22, 2020

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
Copy link
Contributor Author

danielhuang commented Aug 22, 2020

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

@goncalor
Copy link

goncalor commented Aug 22, 2020

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
Copy link

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
Copy link
Contributor Author

--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
Copy link

raffitz commented Aug 22, 2020

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

@goncalor
Copy link

@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
Copy link
Member

nagisa commented Aug 23, 2020

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
Copy link
Contributor Author

danielhuang commented Aug 23, 2020

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

@NickeZ
Copy link

NickeZ commented Oct 18, 2020

Could someone label this A-reproducibility?

@jyn514
Copy link
Member

jyn514 commented May 4, 2021

Duplicate of #40552.

@jyn514 jyn514 closed this as completed May 4, 2021
@liesauer
Copy link

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

+1

@jerryshell
Copy link

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

Yep, Rust is "memory-safe" language, but is not "developer-safe" language.

In some highly sensitive projects, registry paths leaked in binary can cause a lot of problems. Because the registry path contains the developer's user name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

9 participants