Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

uv projects whose env is set by UV_PROJECT_ENVIRONMENT are never probed: agent scan patches the PATH interpreter and uv tool envs instead, the real env stays vulnerable, and vex attests not_affected

Fermée
#525 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
52/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python, rust
Domaine
cli, security

Piste de recherche

Start in crates/socket-patch-core/src/crawlers/python_crawler.rs at find_local_venv_site_packages (381-385) and the is_python_project global fallback (1719-1724), then run the UV_PROJECT_ENVIRONMENT reproduction in the issue. Done means the configured uv environment is the one inspected and patched, unrelated global or uv-tool environments are not modified, and the scan/VEX results no longer claim an unapplied patch.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

agent:claimed agent:triaged bug bughunt pm:uv priority:p1

[agent] Found by the scheduled uv bug-hunt routine (ledger #310).

Summary

uv lets a project put its environment somewhere other than ./.venv with UV_PROJECT_ENVIRONMENT (an absolute path, or a path relative to the project root). uv's own Docker and CI guides use it (UV_PROJECT_ENVIRONMENT=/opt/venv, .venv-ci, and so on), and uv sync / uv run then install into and run from that directory. socket-patch never reads the variable. find_local_venv_site_packages only probes VIRTUAL_ENV, Pipenv, Poetry, ./.venv and ./venv. So it finds no venv, and get_site_packages_paths falls through to get_global_python_site_packages() (the fallback #504 describes).

In agent mode, a plain socket-patch scan --mode agent (no -g) in such a project:

  • leaves the real uv env unpatched (uv run imports the vulnerable bytes);
  • patches six in the PATH interpreter's site-packages, plus every other global copy with a patch. In my run that included backports.tarfile inside an unrelated uv tool environment (~/.local/share/uv/tools/poetry), which the project doesn't depend on;
  • exits 0 with status: success, and socket-patch vex then attests pkg:pypi/[email protected] as not_affected for the project's product.

In hosted mode, the redirect_pypi_stale_install guard checks the wrong interpreter. A project whose real env still holds the upstream six gets no stale-install warning, while the same project with a plain .venv gets it. VEX was only saved from a false attestation because the system Python happened to have an unpatched six.

Impact

  • The environment the app actually runs in stays vulnerable, while the exit code and the VEX document both say it's fixed. That's a false attestation.
  • A project-scoped command modifies files outside the project, including other tools' uv tool envs and, as root in Docker, the OS Python.

Repro (Linux, uv 0.8.17; the variable is honored the same way by uv 0.5.31; main 61cfb9b)

# stand-in "global" interpreter on PATH with six 1.16.0
uv venv G && uv pip install --python G/bin/python six==1.16.0
mkdir app && cd app
cat > pyproject.toml <<'EOF'
[project]
name = "app"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = ["six==1.16.0", "idna==3.7"]
EOF
uv lock
export UV_PROJECT_ENVIRONMENT=.venv-ci      # or an absolute path such as /opt/venv
uv sync                                      # env lands in ./.venv-ci; there is no ./.venv
PATH=../G/bin:$PATH socket-patch scan --mode agent --yes $API   # exit 0, status success, scannedPackages 118
.venv-ci/bin/python -c "import six; print(getattr(six,'SOCKET_PATCHED',0))"   # 0  <- real env unpatched
../G/bin/python   -c "import six; print(getattr(six,'SOCKET_PATCHED',0))"     # 1  <- PATH interpreter patched
uv run --frozen python -c "import six; print(getattr(six,'SOCKET_PATCHED',0))" # 0
PATH=../G/bin:$PATH socket-patch vex $API -O vex.json             # exit 0: six not_affected for pkg:pypi/[email protected]

The patch API was a local mock serving a free six 1.16.0 patch (the patched six.py appends SOCKET_PATCHED = 1). The absolute-path form (UV_PROJECT_ENVIRONMENT=$TMP/envs/app) gave the same result: real env 0, PATH Python 1, vex not_affected. Each form ran on a fresh project, so it reproduced twice.

Expected vs actual

  • Expected: CLI_CONTRACT.md, "cwd-only (single project)": the crawler inspects only the project rooted at --cwd. For a uv project, that's the environment uv uses for it, which uv sync / uv run take from UV_PROJECT_ENVIRONMENT when it's set (relative paths resolve against the project root). Global installs are the -g / --global-prefix surface only. VEX must not attest a patch that isn't applied in the project's env.
  • Actual: the uv project env is ignored, global and uv-tool copies are patched, and VEX attests.

Cells (Linux)

Shape real env PATH interpreter / uv tool env exit vex
agent, UV_PROJECT_ENVIRONMENT=<abs> (uv 0.8.17) ❌ unpatched ❌ patched 0 ❌ not_affected
agent, UV_PROJECT_ENVIRONMENT=.venv-ci (uv 0.8.17) ❌ unpatched ❌ patched 0 ❌ not_affected
hosted, UV_PROJECT_ENVIRONMENT=<abs>, before re-sync stale, no redirect_pypi_stale_install – 0 omitted (only because system six is unpatched)
control: default ./.venv (hosted) stale-install warning fires – 0 omitted ✅

Untested: macOS and Windows (the probe order is the same code path), and a stray ./.venv next to a UV_PROJECT_ENVIRONMENT env. I'd expect the wrong one to be patched there too.

Related

  • #504 (Pipenv), #476 (Poetry) and #502 (PDM) are the same class: a project env the tool uses but socket-patch doesn't probe, plus the non--g global fallback. This issue is the uv-specific missing probe. Fixing #504's fallback alone would turn the uv case into "nothing patched, exit 0", and the real env would still be missed.

Suspect code

  • crates/socket-patch-core/src/crawlers/python_crawler.rs:381-385: the generic probe only tries <cwd>/.venv and <cwd>/venv. There's no UV_PROJECT_ENVIRONMENT arm, which needs to be resolved relative to the uv project root.
  • crates/socket-patch-core/src/crawlers/python_crawler.rs:1719-1724: the is_python_project → global fallback (see #504).
Langage dominant
Rust
Étoiles
8
Forks
0
Merge moyen
22 h 30 min
PR mergées (30 j)
329

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.