GeezerVison

The World Wide Web, restored to 800 pixels of glory.

GeezerVison is showing github.com — Fix hosted PyPI pinning platform-only wheels (#701, #932) by mikolalysenko · Pull Request #984 · SocketDev/socket-patch

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 7, 2026 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

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

Fixes #701
Fixes #932

Root cause

Every hosted PyPI lock writer is dispatched from rewrite_registry_redirect_withholding_vlt in crates/socket-patch-core/src/patch/redirect/mod.rs: requirements.txt, Hatch, uv.lock, PEP 723 script locks, pylock.toml, Poetry, PDM and Pipfile.lock. None of them looks at the granted wheel's tags. When the patch service grants a platform/ABI-tagged wheel (…-cp311-cp311-manylinux…whl), each writer narrows a cross-platform lock entry to that single wheel. The scan reports success, and installs on any other Python, OS or architecture then fail. Vendored mode already parses the tags (wheel_platform_from_filename → vendor_platform_locked), and hosted gem already fails closed on the equivalent case (redirect_gem_platform_unsupported).

Change

One gate at the shared boundary. pypi_platform_wheel_refusal refuses a pypi override whose artifact is a wheel whose tag triple isn't <py>-none-any. withhold_pypi_platform_wheels runs it once at the top of the dispatch, before pdm and Pipenv, so the patch is withheld from every PyPI rewriter and reported once as redirect_pypi_platform_wheel. Nothing is written or confirmed for that patch, so a same-run --vex doesn't attest it. Hosted refusals exit 0 with a warning, which is the existing contract precedent. Sibling patches in the same run are unaffected.
Vendored → hosted takeover. The takeover reverts a vendored PyPI purl before the rewriters run, so a platform grant would have stripped a live vendored patch and stranded the package. The takeover now asks the same refusal before it reverts anything, and the package stays vendored and patched, on the dry run too.
Shared rule. The tag classifier moved from vendor/pypi.rs to vendor/pypi_distribution.rs, so vendored and hosted mode agree on which wheels are portable. The group-equivalence oracle mirrors the new prefix step.
Docs. CLI_CONTRACT.md documents redirect_pypi_platform_wheel.
Inherited CI fix. main is red on test (macos/windows) and coverage because of utils::digest::tests::production_digests_go_through_the_helpers. I cherry-picked Route Gradle digests through utils::digest #878's fix (3298cee); it becomes a no-op once Route Gradle digests through utils::digest #878 merges.

I chose refuse over warn to match hosted gem, and because the warn-only alternative leaves a lock that breaks every other platform and that hosted rollback can't undo. Vendored mode keeps its existing warn-only vendor_platform_locked behavior.

Test evidence (red → green)

Every new test fails on main's logic (gate disabled) and passes with the fix:

Issue	Lane	Test
#701	uv.lock (LF + CRLF)	`platform_wheel_tests::uv_project_lock_refuses_a_platform_wheel`
#701	PEP 723 script lock	`platform_wheel_tests::uv_script_lock_refuses_a_platform_wheel`
#701	pylock.toml	`platform_wheel_tests::pylock_refuses_a_platform_wheel`
#701	requirements.txt (LF, CRLF, hashed)	`platform_wheel_tests::requirements_refuses_a_platform_wheel`
#932	Pipfile.lock (Pipenv 11 / 2026 / unknown)	`platform_wheel_tests::pipfile_lock_refuses_a_platform_wheel`
#932	CLI end to end: Pipfile.lock + sibling requirements.txt untouched, exit 0, VEX doesn't attest	`in_process_redirect_pipenv::platform_wheel_is_not_pinned_into_the_lock`
both	poetry.lock, pdm.lock, Hatch pyproject	`platform_wheel_tests::{poetry,pdm,hatch}_*`
both	tag rule (cp311-none-any, sdist, abi3, win_amd64, query/fragment)	`platform_wheel_tests::only_platform_or_abi_tagged_wheels_are_withheld`
both	per-patch withholding, npm ignored	`platform_wheel_tests::a_platform_wheel_withholds_only_its_own_patch`
both	vendored → hosted takeover refused before revert (wet + dry)	`mode_migration_pypi::platform_wheel_takeover_is_refused_before_revert`

Without the gate: 0 passed; 10 failed for platform_wheel_tests. The CLI test shows the cp311 wheel written into Pipfile.lock (the #932 symptom), and the takeover test reports redirect_takeover_reverted_vendored. With the fix all of them pass.

Local runs.

cargo clippy --workspace --all-features -- -D warnings is clean.
cargo test --workspace --all-features --no-fail-fast: 10,829 passed. The 12 failures are all permission-injection tests (chmod 0o555 / unremovable-file cases in covgap_commands_vendor, in_process_redirect, repair, and core copy_tree / vlt_heal / pypi_poetry / pypi_requirements). They fail only because this sandbox runs as root, which ignores file modes, and none touch this diff.
e2e_redirect_uv_build --include-ignored with uv 0.11.32: 18/22 pass. The 4 rollback lanes fail only because the sandbox's TLS proxy blocks the binary's pypi.org restore fetch (error sending request for url (https://pypi.org/pypi/six/1.16.0/json)); CI has direct access.
I didn't run a repo-wide cargo fmt --all because main has ~466 rustfmt diffs and CI has no fmt job. My hunks are rustfmt-clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Eh8HJTpZnGoKmxzQMniJHa

Note

Medium Risk
Changes hosted scan/redirect behavior for PyPI grants and vendored→hosted takeover paths; mistakes could block valid redirects or leave bad pins, but the change is narrowly scoped with broad test coverage.

Overview
Hosted PyPI redirect now refuses to pin patches when the granted artifact is a platform- or ABI-tagged wheel (anything other than a portable py-none-any wheel). A shared early gate (pypi_platform_wheel_refusal / withhold_pypi_platform_wheels) withholds those patches from all PyPI lock rewriters, emits redirect_pypi_platform_wheel once, leaves lockfiles unchanged, exits 0, and skips same-run VEX attestation—matching the hosted-gem fail-closed pattern.

Vendored → hosted takeover checks the same rule before reverting a live vendored PyPI patch, so a platform grant cannot strip vendoring and strand the package unpatched (wet and dry run).

Wheel tag classification is centralized in pypi_distribution so vendored vendor_platform_locked and hosted redirect share one rule. Several call sites now use utils::digest helpers for SHA1/SHA256 instead of inline hashing. CLI contract documents the new warning; tests cover every PyPI lane, takeover, and Pipenv CLI behavior.

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions


          Start fix for #701, #932

ff82eda

Assisted-by: Claude Code:claude-opus-5-5

This was referenced Oct 7, 2026

Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701

Closed

Hosted Pipenv scan silently rewrites a Pipfile.lock entry to a single platform-specific patched wheel (cp311 manylinux), so pipenv sync fails on every other Python version, macOS and Windows #932

Closed

Claude (claude) added 4 commits

October 7, 2026 04:55


          Stop hosted PyPI pinning platform-only wheels

e50feee

When the patch service granted a PyPI patch as a platform- or
ABI-tagged wheel (for example cp311 manylinux), hosted scan pinned
that one wheel into the project's cross-platform lock: uv.lock, PEP
723 script locks, pylock.toml, Pipfile.lock, poetry.lock, pdm.lock,
requirements.txt or Hatch's pyproject. It reported success, but
installs then failed on every other Python version, OS and
architecture, and hosted rollback refused to undo it.

Hosted mode now checks the granted wheel's tags once, where every
PyPI lock writer is dispatched. A platform-specific wheel is withheld
from all of them and reported with a redirect_pypi_platform_wheel
warning, the same way hosted gem refuses platform gems. Nothing is
written or attested for that patch; other patches in the run are
unaffected. The tag rule is the one vendored mode already uses for
vendor_platform_locked, now shared between both modes.

Fixes #701, #932.

Assisted-by: Claude Code:claude-opus-5-5


          Keep vendored PyPI patch on a platform grant

139fa65

A vendored PyPI package that a hosted scan takes over is reverted to
its registry entry first, and only then pinned to the hosted wheel.
With platform-tagged hosted wheels now refused, that order would strip
the live vendored patch and leave the package unpatched.

The takeover now asks the same platform-wheel check before it reverts
anything, so the package stays vendored and patched, and both the wet
run and the dry run name redirect_pypi_platform_wheel as the reason.

Refs #701, #932.

Assisted-by: Claude Code:claude-opus-5-5


          Format the takeover test's hosted route

041dc48

Assisted-by: Claude Code:claude-opus-5-5


          Route Gradle digests through utils::digest

3298cee

main has failed socket-patch-core's lib tests since Gradle support
(#646) and the digest helpers (#865) both landed. The guard test
production_digests_go_through_the_helpers flags three files #646 added
that still hash inline: crawlers/gradle_cache.rs, patch/jvm_jar.rs and
patch/sidecars/maven.rs. That breaks test, test-release and coverage on
every open PR.

Each inline sha1/sha256 call now goes through sha1_hex_of or
sha256_hex_of, which compute the same lowercase hex. Behaviour is
unchanged.

Assisted-by: Claude Code:claude-opus-5-5
(cherry picked from commit 659ac2c)

Mikola Lysenko (mikolalysenko) commented Oct 7, 2026

Copy link

Copy Markdown

Collaborator Author

[agent] test (macos-latest), test (windows-latest) and coverage failed on the empty start commit ff82eda. That failure isn't from this PR: the same three checks are red on main (9c43dfc, run 37420351192). The one failing test is utils::digest::tests::production_digests_go_through_the_helpers: the Gradle files from #646 hash inline (crawlers/gradle_cache.rs, patch/jvm_jar.rs, patch/sidecars/maven.rs), and #865's guard test rejects inline hashing. I ported #878's fix (659ac2c, cherry-picked as 3298cee) into this branch. It becomes a no-op once #878 lands on main.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.


          Check the Pipenv refusal exit code without VEX

8725c55

The new Pipenv platform-wheel test asserted exit 0 on a run that also
asked for --vex. With nothing pinned, VEX correctly fails with
manifest_not_found, so the run exits 1 and the coverage job failed.

Assert the hosted refusal's exit 0 on a plain scan, then run --vex
separately and check only that it attests nothing.

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) marked this pull request as ready for review

October 7, 2026 05:34

Mikola Lysenko (mikolalysenko) commented Oct 7, 2026

Copy link

Copy Markdown

Collaborator Author

BugBot review

Generated by Claude Code

cursor[bot] reacted with thumbs up emoji

All reactions

👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot reviewed

Oct 7, 2026

View reviewed changes

cursor Bot left a comment

Copy link

Copy Markdown

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ 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 8725c55. Configure here.}

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Mikola Lysenko (mikolalysenko) added the Ready for review Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review label

Oct 7, 2026

Mikola Lysenko (mikolalysenko) commented Oct 7, 2026

Copy link

Copy Markdown

Collaborator Author

[agent] Ready for review at 8725c55.

CI: 547/547 check runs on 8725c55 are green or skipped.
Bugbot: reviewed 8725c55 and found no issues. There are no open review threads.
Look at: the refusal is deliberate (it matches hosted gem's redirect_gem_platform_unsupported). A platform/ABI-tagged wheel grant is now withheld from every hosted PyPI lock writer and reported as redirect_pypi_platform_wheel, instead of narrowing a cross-platform lock to one wheel. The PR carries Route Gradle digests through utils::digest #878's digest-helper fix, which becomes a no-op once Route Gradle digests through utils::digest #878 merges.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Tanmay Singla (Tanmay182003) approved these changes

Oct 7, 2026

View reviewed changes

Mikola Lysenko (mikolalysenko) merged commit 23fd62e into main

Oct 7, 2026

548 checks passed

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) deleted the agent/fix-hosted-pypi-platform-wheel branch

October 7, 2026 12:39

This was referenced Oct 7, 2026

Fix PyPI hosted takeover un-vendoring before refusal (#723, #945) #946

Merged

Hosted Pipenv scan still pins an interpreter-bound cp311-none-any patched wheel into Pipfile.lock with no warning, so pipenv sync fails on every other Python version (gap in the #932 fix) #1048

Closed

Reviewers

cursor[bot]

cursor[bot] left review comments

Tanmay Singla (Tanmay182003)

Tanmay182003 approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

Ready for review

Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Hosted Pipenv scan silently rewrites a Pipfile.lock entry to a single platform-specific patched wheel (cp311 manylinux), so pipenv sync fails on every other Python version, macOS and Windows Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses

Uh oh!

There was an error while loading. Please reload this page.

3 participants

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.

GeezerVison

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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

Root cause

Change

Test evidence (red → green)

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 7, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 7, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 7, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Mikola Lysenko (mikolalysenko) commented Oct 7, 2026 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.