ecosystem_domains.json: python entry contains crates.io domains

[jamesadevine]

The python entry in pkg/workflow/data/ecosystem_domains.json includes three Rust registry domains that don't belong:

"python": [
    "pypi.python.org",
    "pypi.org",
    ...
    "crates.io",
    "index.crates.io",
    "static.crates.io"
]

These are Rust package registry domains already correctly listed under the rust entry. Their presence in python means any workflow using network.allow: [python] silently receives access to the Rust registry — violating least-privilege network isolation.

Looks like a copy-paste error. Suggested fix: remove the three crates.io entries from the python array.

[jamesadevine]

Could be used for tools like uv (if downloading artifacts from crates io?)

[pelikhan]

/scout research history why crates is in python domains. Related to uv?

[github-actions]

🔭 Recon complete! Scout has charted the territory. Map ready! 🗺️

[github-actions]

🔍 Scout Research Report

Triggered by @pelikhan

Executive Summary

The crates.io domains in the Python section are almost certainly a copy-paste error or a misunderstanding related to uv, not a legitimate runtime requirement. uv (the Python package manager by Astral) is written in Rust and published on crates.io, but Python workflows using uv to install packages never contact crates.io at runtime — they only contact PyPI. The crates.io domains would only be needed to build uv from source using Cargo, which is a developer/release task, not a typical Python workflow task.

Why the uv Connection is Plausible

uv sits at the intersection of both ecosystems:

• It is a Python package manager (primary audience: Python developers)
• It is written in Rust and its source lives in [crates.io/crates/uv]((crates.io/redacted)
• It is published on both pypi.org/project/uv and crates.io

Click to expand detailed findings

Research Findings

Does uv Require crates.io at Runtime?

No. When a Python workflow uses uv to install packages:

• uv contacts PyPI domains (pypi.org, files.pythonhosted.org) to resolve and download Python packages
• uv does not contact crates.io at runtime — those domains are only needed when compiling uv from Rust source via cargo build

End users install uv as a pre-built binary (via curl installer or pip) or copy it from a Docker image (ghcr.io/astral-sh/uv). None of these installation paths require runtime crates.io network access.

Most Likely Cause

Two plausible theories, in descending likelihood:

1. Misunderstanding: When adding uv support for Python workflows, a contributor reasoned "uv is Rust-based and lives on crates.io, so Python workflows using uv need crates.io access." This conflates uv's build-time (crates.io) and runtime (pypi.org) network dependencies.

2. Copy-paste error: The Rust section already has exactly these three domains (crates.io, index.crates.io, static.crates.io). Someone may have copied the Rust domain block and pasted it into the Python block inadvertently.

Current State of the File

"python": [
    "pypi.python.org",
    "pypi.org",
    "pip.pypa.io",
    "*.pythonhosted.org",
    "files.pythonhosted.org",
    "bootstrap.pypa.io",
    "conda.binstar.org",
    "conda.anaconda.org",
    "binstar.org",
    "anaconda.org",
    "repo.continuum.io",
    "repo.anaconda.com",
    "crates.io",          // ❌ Rust registry — belongs in "rust" only
    "index.crates.io",    // ❌ Rust registry — belongs in "rust" only
    "static.crates.io"    // ❌ Rust registry — belongs in "rust" only
],
"rust": ["crates.io", "index.crates.io", "static.crates.io", ...]

Note on Git History

The repo is in a shallow clone — only 1 commit is available locally. A full git fetch --unshallow would be needed to trace the exact commit that introduced the crates.io domains to the Python section. Based on the shallow history, no additional context is available.

Recommendations

1. Remove crates.io, index.crates.io, and static.crates.io from the python array — the fix proposed in the issue body is correct.
2. No replacement needed: uv's runtime operation only requires the existing PyPI domains already in the Python array.
3. Optional consideration: If any workflow needs to build uv from source (very rare), it should use network.allow: [python, rust] explicitly, not contaminate the python entry.

Key Sources

• [uv on crates.io]((crates.io/redacted) — confirms uv is a Rust crate published to crates.io
• [Astral uv announcement]((astral.sh/redacted) — describes uv as "Cargo for Python," installable via pip or standalone binary (no crates.io needed by end users)
• uv GitHub repo — shows crates/ directory used for building, not user-facing

Suggested Next Steps

1. Remove the three crates.io domains from the python array in ecosystem_domains.json
2. Optionally add a comment or PR description noting this was uv-related confusion so it doesn't recur
3. Consider auditing other ecosystem entries for similar cross-contamination

References:

• §24456332315

🔭 Intelligence gathered by Scout · ● 106.7K · ◷

[pelikhan]

@copilot proceed with fixes, remove crates from python