Fix requirements.txt writers ignoring pip hash mode (#376)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #376

Summary

Hosted and vendored scans no longer break pip install -r on a requirements.txt that has no hashes.

Scope: this PR originally also fixed #378 (setup writing an unhashed hook line into a hash-pinned requirements.txt). #277 removed the setup command, so that part was dropped when main was merged in at a2dedc5, and #378 was closed as no longer applicable.

Root cause

pip's hash-checking mode is all or nothing. It turns on for the whole install as soon as any requirement carries --hash, and then every requirement, transitive dependencies included, has to be ==-pinned and hashed. The hosted redirect (patch/redirect/requirements.rs) and the vendored writer (vendor/pypi_requirements.rs::vendor_line) always added --hash, without checking which mode the requirements set was in. In an unhashed file that switches the mode on, and pip then refuses every other line.

Fix

• Shared check: utils::requirements::requires_hashes. It is true when any line has a --hash option (any algorithm) or the file sets --require-hashes. Comments and URL #sha256= fragments don't count.
• Hosted: a hashed file keeps --hash on the patched line, as before. An unhashed file gets name @ <url>#sha256=<hex> instead. Checked by hand:
  • pip 24 and uv 0.8 both verify the fragment (a wrong hash fails the install);
  • the fragment does not turn on pip's hash mode for other lines;
  • it also satisfies hash mode when that mode is on;
  • VEX already reads it (integrity_of).
• Vendored: the mode is taken from the whole requirements tree (the root file plus its -r includes). A hashed tree keeps the vendor line unchanged. An unhashed tree gets the committed wheel path with no --hash, because pip can't read a fragment on a bare path. The inventory, VEX and the in-sync ledger fallback already accept a hashless vendor line.
  • Rebuild guard: when there is no ledger entry, the in-sync rebuild guard falls back to the pin on the wired line. A hashless line now still pins its wheel path (wired_pin_in returns an empty sha256 and pin_matches checks the path only). A rebuild under another filename is refused instead of leaving the line pointing at a missing file. Bugbot found this; it is fixed in fcc4fcc.
• Re-scans are no-ops: every line counts toward the mode, the writer's own lines included, so a re-scan never flips a file between the two shapes. A file that an older version already wrote with --hash into an unhashed set keeps that shape; running rollback followed by a re-scan rewrites it in the new form.

Checklist

• Hosted: redirect::requirements::tests::unhashed_file_pins_the_artifact_by_url_fragment_not_hash_option and hashed_file_keeps_the_hash_option. Both were red before the fix and are green after.
• Vendored: vendor::pypi_requirements::tests::unhashed_requirements_get_an_unhashed_vendor_line (red → green) and hashes_in_an_include_keep_the_vendor_line_hashed.
• Vendored rebuild guard: vendor::pypi::tests::in_sync_ledgerless_rebuild_of_unhashed_line_keeps_the_wired_path (red → green).
• Real pip: a new unhashed cell (six==1.16.0 + idna==3.7) in e2e_vex_build::pip. Locally on pip 24.3.1 every hosted and vendored step passes: wire, install-patched, manifest-less VEX, re-scan.
• Shared check: utils::requirements::tests::requires_hashes_reads_pip_hash_checking_mode.

Test updates (intended behavior change)

Several existing tests expected --hash in unhashed files, which is the #376 bug itself. They now expect the unhashed forms:

• the unit tests in the hosted and vendored writers;
• the redirect fixture and the VEX discovery golden (redirect-pypi.json);
• in_process_get_hosted_ecosystems, e2e_hosted_production, e2e_vendored_production and e2e_vendor_pypi_build.

Two tests needed more than a new expected string:

• vendor_ledger_schema_e2e: the base-binary parity test now names this one intended difference. The legacy fixtures are unchanged, so the legacy-revert coverage stays.
• The pin-guard tests and the marker e2e rely on a hashed pin, so their inputs are now hash-pinned.

An earlier commit on this branch accidentally reformatted about 55 unrelated files, and e0ed1aa reverts them. main isn't rustfmt-clean and CI doesn't check formatting, so this PR leaves formatting alone.

Evidence

• cargo clippy --workspace --all-features -- -D warnings: clean on fcc4fcc.
• cargo test --workspace --all-features (local, sandbox runs as root): every failure is a test that needs a write, removal or permission check to fail, which root bypasses. None exercises code this PR changes.
• SOCKET_PATCH_PIP_E2E_VERSIONS=24 SOCKET_PATCH_PIP_E2E_REQUIRED=1 cargo test -p socket-patch-cli --all-features --test e2e_vex_build -- pip:: --ignored: passes for all 4 cells × 2 modes (pre-merge).
• CI is green on fcc4fcc, and Bugbot found no new issues on it.
• Not touched: the npm, pypi and gem wrappers (they only dispatch to the binary).

🤖 Generated with Claude Code

https://claude.ai/code/session_017aQf44e9818AbFKDYnuAHZ

---

Note

Medium Risk
Changes how hosted and vendored requirements.txt pins are written, which affects install behavior for mixed hashed/unhashed projects; behavior is heavily tested but wrong detection could weaken or break installs.

Overview
Fixes pip breaking when requirements.txt is patched in an unhashed tree (#376). Hosted and vendored rewrites no longer unconditionally add --hash, which turns on pip’s global hash-checking mode and rejects every other requirement.

A shared requires_hashes helper detects whether the file (or included tree) is already in hash-checking mode. Hosted redirects pin integrity with a URL #sha256= fragment when the file is unhashed, and keep --hash when it is already hashed. Vendored wheel lines omit --hash in unhashed trees (path-only pin); the in-sync rebuild guard treats an empty sha256 as path-only via pin_matches.

CLI contract, redirect/VEX fixtures, and e2e tests (including a new pip VEX unhashed cell) are updated to match the new shapes.

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

[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]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

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 fcc4fcc. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[burn-down agent] Ready for review on fcc4fcc: mergeable, 0 commits behind main.

• CI: all completed checks green on fcc4fcc (3 skipped by workflow conditions).
• Bugbot: reviewed fcc4fcc, no new issues. Its earlier finding on a2dedc5 (pin guard on hashless vendor lines) is fixed by fcc4fcc; thread resolved.
• Reviewer note: only the Hosted and vendored requirements.txt rewrites add a --hash to one line, which turns on pip's hash-checking mode and breaks pip install -r for every other unhashed line #376 half remains. The setup appends an unpinned, unhashed socket-patch[hook] line to a hash-pinned requirements.txt, so pip install -r fails in hash-checking mode #378 setup half was dropped when merging main, because v5 prerelease: scan → vex → vendor workflow, hosted by default #277 removed setup; the description now says so. Main thing to review is the hashless path that writes name @ url#sha256=.

---

Generated by Claude Code