[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1873

Summary

A pip requirement written with an environment variable (six==${SIXV})
beside a pip lock pylock.toml left six on PyPI. Vendor wired only the
lock and exited 0, vendor --check passed, and vex attested
not_affected while pip install -r requirements.txt installed the
unpatched release. Such a line now fails closed:

• vendor refuses it with pypi_requirement_env_templated and writes
  nothing. That applies in the root file or an include, and beside a
  pylock / Pipfile.lock / uv.lock / poetry.lock instead of naming
  requirements.txt an unpatched pypi_multiple_lockfiles loser. Without
  a lock it used to say the misleading pypi_requirement_not_pinned.
• VEX discovery / vendor --check read it as possibly installing any
  release of the package from PyPI, so it contests every wiring of that
  package (vendor --check exits 1, VEX drops the attestation).

Root cause

pip runs expand_env_variables on every requirements line before parsing
it. socket-patch only knew ${NAME} for -r/-c include targets, so the
planner (scan_pins) and discovery (pypi_other::requirements_line)
read six==${SIXV} as no pin at all, and nothing contested the
pylock-only wiring.

Design choice: refuse, don't expand

The first commit expanded the line from this process's environment.
/code-review high showed why that's wrong: pip expands where it
installs, often in a Docker ARG or CI step this process never sees.
So vendor --check would pass wherever the variable is unset, and a
vendor rewrite would freeze one environment's value into the file. The
final fix is env-independent. A line naming the package through a
pip-expandable ${NAME} (pip's [A-Z0-9_]+ grammar) is "unknown
release": the planner refuses it and discovery records any-version
evidence (resolved_elsewhere_any_version, as for editable installs).
This is the issue's "at minimum" option, and it's the only one that's
sound when the check runs somewhere other than the install.

Code-review findings, each with how it was handled:

• check-env vs install-env, and the rewrite dropping the template: fixed by the redesign.
• hash options or --require-hashes hidden in a variable: a templated hash on the pin is refused (tested). A file-level ${VAR} that expands to --require-hashes is not detected. That's a pre-existing gap outside Vendored pip: a six==${SIXV} pin in requirements.txt (pip expands ${VAR} on every line) doesn't contest a pylock.toml wiring, so vendor --check passes and vex attests not_affected while pip install -r installs the unpatched release #1873.
• tests mutating the process env: removed. The tests no longer depend on the environment.
• lock inventory / hosted mode not expanding: not changed. The inventory doesn't offer a templated pin, which is consistent with the refusal. The issue confirms hosted already doesn't attest (redirect_unconfirmed).
• a String allocated per line: short-circuited on ${.

Tests (red → green)

Issue	Test	Without fix	With fix
#1873 planner	vendor::pypi_requirements::tests::refuses_an_env_templated_pin (root, include, --hash=${..}, lowercase stays literal)	FAILED	ok
#1873 VEX/check	vex::discover::pypi_other::tests::issue_1873_env_templated_pin_contests_wiring	FAILED	ok
#1873 CLI	mode_migration_pypi::pip_lock_vendor_refuses_an_env_templated_requirements_pin: vendor refuses beside a pip-lock pylock with and without the var set; a pylock-only wiring the templated line contests fails vendor --check	FAILED	ok

The "without fix" column is the same tests run with has_env_reference stubbed to false.

Local runs:

• cargo fmt --all -- --check: ok.
• cargo clippy --workspace --all-features -- -D warnings: ok.
• cargo test -p socket-patch-core --all-features --lib: 6996 passed, 4 failed. All 4 are pre-existing read-only-directory tests (copy_tree, vlt_heal, pypi_poetry / pypi_requirements write-failure) that can't fail as root in this container. They're unrelated to this diff.
• cargo test -p socket-patch-cli --all-features --test mode_migration_pypi --test in_process_vendor: 147 + 75 passed.
• The full workspace and the real-pip e2e suites didn't fit this container's disk allowance, so they're left to CI.

A final reviewer pushed d97f89c, which adds governing_lock_refuses_an_env_templated_requirements_pin to cover the refusal's Pipfile.lock / governing-lock branch.

Known gaps outside #1873, left for follow-up:

• A line whose name or whole requirement is templated (${PKG}==1.0, ${SIX_REQ}) has no readable name, so it is neither refused nor counted as evidence.
• A non-UTF-8 root requirements.txt still falls back to the pypi_multiple_lockfiles loser warning.
• A ${TOKEN} credential in the target's direct-reference URL is refused with pypi_requirement_env_templated. That's fail-closed, but the "release it installs is unknown" wording fits it loosely.

Wrappers (npm/, pypi/, gem/) only dispatch to the binary, so they need no change.

https://claude.ai/code/session_011f9aePT5mRBMMA1kpcGZBU

---

Note

Medium Risk
Changes PyPI vendor routing and VEX contest logic for requirements beside locks; behavior is fail-closed but affects install attestation and vendor --check outcomes.

Overview
Fixes #1873: requirements lines like six==${SIXV} are no longer ignored when a pylock or other governing lock is wired.

Vendor now detects pip-expandable ${NAME} (uppercase [A-Z0-9_]+) via new has_env_reference, treats those pins as an unknowable release, and refuses with pypi_requirement_env_templated instead of wiring the lock alone or mislabeling the line as “not pinned.” That applies to requirements-only wiring and to lock paths that call refuse_templated_pin (pylock, Pipfile.lock, uv.lock, etc.). Nothing is rewritten and the template is not expanded from this process’s environment.

VEX / vendor --check route templated registry lines through registry_line → resolved_elsewhere_any_version, so they contest every wiring of that package (same idea as editable “any version” evidence). Lowercase ${...} stays literal and is unchanged.

Tests cover planner refusal, governing-lock detection, CLI beside pip-lock pylock, and discovery contest behavior.

^{Reviewed by Cursor Bugbot for commit ddc9e88. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Ready for review at 28a6249 (burn-down agent).

• CI: 82/82 checks green on the head (32 success, 50 skipped, no failures). No main-wide failures.
• Bugbot: Cursor Bugbot check passed on this head; no open review threads.
• Mergeable with no conflicts; no CHANGELOG.md change.

Slack announcement not sent this run (the Slack send tool was unavailable); a later run will retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

Final reviewer: I pushed d97f89c.

The new test. refuse_templated_pin runs in two branches of detect_pypi_flavor, and only the pylock branch had a test. When the governing-lock call (pypi.rs:472) was removed, every core lib and mode_migration_pypi test still passed. The new test, governing_lock_refuses_an_env_templated_requirements_pin, sets up a Pipfile.lock project whose requirements.txt has six==${SIXV}. It passes with the call and fails without it.

Two non-blocking gaps the description could list. Both are outside #1873:

• A line whose name or whole requirement is templated (${PKG}==1.0, ${SIX_REQ}) has no readable name, so it is neither refused nor counted as evidence.
• A non-UTF-8 root requirements.txt falls back to the old loser warning.

A wording mismatch. A ${TOKEN} credential in the target's direct-reference URL is now refused with the templated code. That is fail-closed, but the message "the release it installs is unknown" fits this case a little loosely.

I removed Ready for review until CI and Bugbot are green on the new head.

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Final reviewer: claim released. d97f89c from an earlier final-review run already covers the governing-lock refusal I was going to test, so I pushed nothing. My separate review of 28a6249 found nothing that blocks merging.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Ready for review at d97f89c (burn-down agent).

• CI: 50/50 checks green on the head (31 success, 19 path-skipped), no failures.
• Bugbot: reviewed d97f89c, no new issues; no unresolved review threads.
• Mergeable, no conflicts; no CHANGELOG.md change.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief (d97f89c)

What it does. pip expands ${VAR} on every line of a requirements file, so a line like six==${SIXV} pins whatever release that variable names on the installing machine. socket-patch read such a line as no pin. Beside a pip-lock pylock.toml it wired only the lock, and vendor --check and vex then reported the patch as effective while pip installed the unpatched release (#1873). Now the planner refuses a line that names the patched package through a variable, with the new code pypi_requirement_env_templated, and writes nothing. VEX discovery and vendor --check treat that line as possibly installing any release.

Risk: low. This is fail-closed and narrow. The new check only looks for a variable reference using pip's own [A-Z0-9_]+ grammar. It never reads the environment, and the refusal message holds only the relative path and the package name.

Look here

• has_env_reference
• planner skip/refuse in scan_pins and plan_requirements
• templated_pin
• refusal call sites: pip-lock branch and governing-lock branch
• VEX discovery evidence

Verified

• Read the full diff and Vendored pip: a six==${SIXV} pin in requirements.txt (pip expands ${VAR} on every line) doesn't contest a pylock.toml wiring, so vendor --check passes and vex attests not_affected while pip install -r installs the unpatched release #1873.
• The new core tests and the CLI test pip_lock_vendor_refuses_an_env_templated_requirements_pin pass.
• --test mode_migration_pypi: 75/75 passed.
• Stubbed has_env_reference to false: all 4 new tests then fail. Removing only the governing-lock refusal makes its own test fail. So the tests catch both.
• cargo clippy --workspace -- -D warnings is clean, and fmt is clean.
• CI on d97f89c: 50/50 check runs, 31 passed and 19 skipped. Bugbot found no issues. No open review threads. CHANGELOG.md is untouched.

Changes I made: none.

Open questions (worth a conscious OK, not blocking)

• Behaviour change in the governing-lock branch (pypi.rs:472). With a Pipfile.lock, uv.lock or poetry.lock plus a root requirements.txt that templates the patched package, vendor now fails with a hard error. Before, requirements.txt was only reported as an unpatched pypi_multiple_lockfiles loser. This is the stricter option that Vendored pip: a six==${SIXV} pin in requirements.txt (pip expands ${VAR} on every line) doesn't contest a pylock.toml wiring, so vendor --check passes and vex attests not_affected while pip install -r installs the unpatched release #1873 offers.
• templated_pin uses .ok()?, so if collecting the requirements files fails (for example a non-UTF-8 root), it does not refuse. This gap is already disclosed and unchanged from before.
• Also disclosed and not covered: a templated name or whole line (${PKG}==1), and a templated URL or path line.

Auto-merge is armed, so approving sends this straight to the merge queue.

Update: head is now eb89ff0, which differs from d97f89c only by a merge from main (bringing in cbbbdb9, #1796). The brief still applies; ci-ok and clippy are green on the new head.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: merged main (cbbbdb9) to clear the conflict and re-labeled Ready for review.

• Head: eb89ff00c21f1fcda9df555e0832a6a326c46c1b, mergeable.
• Conflict: vendor/pypi_requirements.rs against Fix extras pin un-hosted beside a pylock (#1794) #1796 (extras pin beside a pylock). scan_pins now keeps both the ${VAR} templated-pin refusal and main's named_lines/exact_extras tracking; a templated line still counts as a line naming the package. Both templated_refusal/templated_pin and main's extras_refusal/fresh_sibling_pin are kept, and the match arm uses the shared extras_refusal.
• Local: cargo check -p socket-patch-core --all-targets clean; mode_migration_pypi 77/77; core pypi lib tests pass except two permission-based tests that fail only when run as root (the sandbox is root).
• CI: 31/31 ran green (19 skipped by path filters).
• Bugbot: reviewed this head, no new issues.
• Auto-merge left armed (only a merge from base was pushed).
• Slack announcement could not be sent this run (send tool unavailable); next run retries.

---

Generated by Claude Code

[Wenxin Jiang (Wenxin-Jiang)]

[agent] Reviewed eb89ff00c21f1fcda9df555e0832a6a326c46c1b. Checked templated requirements refusal through planning and VEX evidence. No major correctness issues found. Validation: source and regression-test review plus the available exact-head CI checks; no local test pass is claimed.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit ddc9e88. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[final reviewer] Re-enqueued at ddc9e88e7: approved (approval stays valid after the post-approval pushes), ci-ok and clippy green, mergeable, no unresolved threads. Armed squash auto-merge, which put it back into the merge queue after the earlier dequeue.

---

Generated by Claude Code