The dependency confusion attack could exploit human error in editing of Cargo.toml. If a user wrote:
[dependencies]
company-internal-utils = "1"
when they've meant:
[dependencies]
company-internal-utils = { version = "1", registry = "internal" }
cargo build could end up fetching and running code from a wrong crate in the public crates.io registry.
I think this mistake could be detected by checking whether a dependency is in both internal and public crates.io registry. I'm not sure if Cargo could treat it as a hard error — that would be a breaking change, but at least it could warn about it.
Now, if Cargo detects such accidentally-from-crates.io dependencies as ambiguous, there needs to be a way to specify that a dependency was really meant to come from crates.io. For this I suggest supporting registry="crates.io", e.g.
[dependencies]
# Not an accident, I really mean the public one:
company-internal-utils = { version = "1", registry = "crates.io" }
The dependency confusion attack could exploit human error in editing of Cargo.toml. If a user wrote:
when they've meant:
cargo buildcould end up fetching and running code from a wrong crate in the public crates.io registry.I think this mistake could be detected by checking whether a dependency is in both internal and public crates.io registry. I'm not sure if Cargo could treat it as a hard error — that would be a breaking change, but at least it could warn about it.
Now, if Cargo detects such accidentally-from-crates.io dependencies as ambiguous, there needs to be a way to specify that a dependency was really meant to come from crates.io. For this I suggest supporting
registry="crates.io", e.g.