Security hardening: cargo install should warn when installing binaries that conflict with existing $PATH executables

[rlneumiller]

Problem

Summary:
When a binary is installed via cargo install, Cargo does not verify whether a binary with the same name already exists elsewhere in the $PATH. This can unintentionally shadow critical system tools or other software, introducing both usability problems and potential security risks.

Security Implications:

A malicious or misnamed crate could install a binary like ls or git, which, if ~/.cargo/bin appears early in the user’s $PATH, would silently override the expected system command.
This presents a software supply chain hazard, especially in CI environments or on shared systems.
Cargo’s current behavior provides no warning or audit mechanism, leaving users unaware of the change in behavior.

Proposed Solution

Proposed Feature: Add a pre-installation hook to cargo install that:

Scans the current $PATH for binaries with the same name
Warns (or optionally halts) if another binary exists outside of the install location (e.g., /usr/bin, /usr/local/bin)
Provides flags for:
--check-conflicts (opt-in stricter enforcement)
--no-conflict-check (to suppress warnings if intentionally overwriting)
Suggested Output Example:

⚠️ Warning: A binary named mytool already exists at /usr/local/bin/mytool.
Installing this crate may override or shadow an existing command in your $PATH.
Benefits:

Improves developer trust and visibility into installed tools
Helps prevent accidental or malicious shadowing of system binaries
Aligns with secure-by-default principles seen in other ecosystems
Related Issues:

Notes

cargo install should allow renaming installed binaries with --name
Improve cargo install --list to show more install metadata

[epage]

Another use case is if someone forgot how they installed a binary and are trying to update it.

The challenge with a warning is it won't be noticed in CI and most won't notice it in general due to the volume of output. I'd love for us to reduce our output but we aren't there yet.

We could make this a lint to allow people to control it but so far our focus on lint control is for package development and doesn't cover cases outside of that.

[epage]

Another question is what to do when customizing the install root, like to a non-PATH location.

[rlneumiller]

I was (still am, but aren't we all?) in the middle of something when this came to my attention as a rustacean wannabe. I hadn't thought it through any further than my immediate reaction after looking up what "cargo install" would do.