cargo publish --index bypasses package.publish restrictions

[AryzXploit]

Description

cargo publish --index <url> bypasses package.publish = [...] restrictions.
When publishing via --index, validate_registry() skips registry name assignment (RegistryOrIndex::Index(_) → None), which causes the publish restriction enforcement block to be skipped entirely.

As a result, crates configured as internal-only can be packaged and processed for publishing to unintended registries.

---

Steps to Reproduce (Safe: uses --dry-run)

mkdir repro && cd repro
cargo new internal_crate --bin
cd internal_crate

Cargo.toml:

[package]
name = "internal_crate"
version = "0.1.0"
edition = "2021"
publish = ["internal-only"]

git init .
git add .
git commit -m "PoC"

Control case (restriction applied):

cargo publish --dry-run

Bypass via --index:

cargo publish --dry-run --index "https://github.com/rust-lang/crates.io-index" --allow-dirty

Actual Behavior

The publish process proceeds through:

Packaging → Verifying → Uploading

(interrupted only due to --dry-run).

Expected Behavior

Publish should be rejected when publish = [...] restrictions are present, regardless of --index.

---

Root Cause

validate_registry() maps RegistryOrIndex::Index(_) to None:

Some(RegistryOrIndex::Registry(r)) => Some(r.as_str()),
None => Some(CRATES_IO_REGISTRY),
Some(RegistryOrIndex::Index(_)) => None,

Restriction enforcement only happens when registry name is Some(_), so using --index suppresses checks.

[fmease]

@rustbot transfer cargo

[epage]

package.publish contains registry names. To do this, we'd have to iterate over the registries and see if the URL is present and map it back to a name. I feel like mapping URLs to registry names had come up previously and we rejected it but I'm unsure where that is.

[ehuss]

The cargo team discussed this and were largely in favor of at least initially adding a warning when using --index and the publish field contains an array. The message should include a suggestion to use --registry instead, or to set publish=true to silence the warning.

• It's unclear if we would want to aim specifically to make this an error in the future. I don't have enough information to know if anyone actually uses --index intentionally in this situation.
• One idea would be to have a special registry name that indicates a cli-index provided value that you could add to the publish array, but there was some concern about adding complexity here for an edge case.

(Not sure if anyone in the meeting has anything to add here.)

[epage]

The message should include a suggestion to use --registry instead, or to set publish=true to silence the warning.

If a registry entry exists, we can suggest that.

If it doesn't exist, we can tell the user how to create one.

It's unclear if we would want to aim specifically to make this an error in the future. I don't have enough information to know if anyone actually uses --index intentionally in this situation.

If we decide to error, we could make it conditioned on a new edition. This works because one of the error conditions (package.publish) is per-package.