Compute sha256, sha1 and SRI digests through utils::digest (#706) by mikolalysenko · Pull Request #865 · SocketDev/socket-patch

Mikola Lysenko (mikolalysenko) · 2026-10-05T13:59:12Z

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

Part of #706 (slice 1; the issue stays open for slice 2)

Summary

utils::digest held only the pin validators, while the computations were written out inline or as private copies, and some of those copies shared a name with a validator (sha256_hex). This PR adds the computations to utils::digest: sha256_hex_of, sha1_hex_of, sha512_base64_of and sha512_sri_of. It moves every production digest site in the 14 files no open PR changes onto them, and deletes the copies.

Why

Issue #706, register row C17 in discussion #560; living document Part 7, "Digest helpers".
Leverage: B 0, U 1 (Agent-mode apply and rollback reject a manifest hash in uppercase hex that blob download accepts as valid #707's single hash-comparison rule builds on these helpers), D ≈ 6 (4 named copies plus about 20 inline sites collapse to one module), R L. This was the top-ranked candidate that no open PR overlaps.

What changed

utils/digest.rs: the four *_of helpers. The _of suffix keeps a helper that computes a digest from sharing a name with a validator. The file also gains a known-vector test and a ratchet test.
These copies are deleted: vendor/ledger_snapshots::sha256_hex, patch/redirect/vlt_preflight::sha512_sri, vendor/nuget_feed::content_hash, api/client::is_valid_sha256_hex (now digest::is_hex(s, 64)), the SRI format! blocks in npm_pack and bun_lock, and the inline hex::encode(ShaN::digest(..)) sites in policy, update/download, bun_workspace, bun_binary, state, verify, service_fetch, reuse, registry_fetch, nuget_feed and redirect/upstream/client.
Test modules that got sha2 through use super::* now import it themselves. Test fixtures keep their own independent digest oracles.

Deleted (`git diff --stat`)

19 files: +190 / −116 in total.
Production code: about +45 / −105. That is the four helpers, plus 24 sites, 4 functions and 18 imports deleted.
Tests: about +145 / −11 (the known-vector test, the ratchet test and test-module imports).

Behavior

None. Every helper produces the same lowercase hex or padded standard base64 the inline copies produced, and is_hex(s, 64) is byte-for-byte the deleted is_valid_sha256_hex.

Tests

computations_match_known_vectors pins "" and "abc" for sha256, sha1 and sha512-base64/SRI (checked against openssl dgst). It also checks that each output passes the module's own validators (is_hex64_lower, sha1_hex, is_sri_pin).
production_digests_go_through_the_helpers is a ratchet. It scans socket-patch-core/src (CRLF-normalized) and fails on a new inline digest in production code, and also on a stale entry in PENDING_INLINE_DIGESTS. The pending list holds the 6 slice-2 files: utils/group_commit.rs, vendor/jvm/mod.rs, vendor/maven_repo.rs, vendor/pypi.rs, vendor/redownload.rs, vendor/yarn_berry_lock.rs.
The existing callers' tests pass through the shared helpers: vlt_preflight, npm_manifest, ledger_snapshots, nuget_feed and the client blob-hash guard tests.
Commands:
- cargo clippy --workspace --all-features -- -D warnings: clean.
- cargo test -p socket-patch-core --lib: 5047 passed, 4 failed. These are the 4 known root-only failures, which fail on main too: relax_loop_must_not_traverse_symlinked_root, an_unremovable_hidden_lock_keeps_every_store_entry, wire_write_failure_maps_error_and_leaves_lock_untouched, wire_failure_rolls_back_already_written_files.
- cargo test -p socket-patch-cli --all-features --lib: 840 passed.
- cargo test -p socket-patch-cli --all-features --test in_process_redirect: 111 passed, 3 failed. All 3 fail only because the sandbox runs as root (each chmods a directory to 0o555): partial_lockfile_write_failure_exits_1_and_writes_no_ledger, redirect_json_mode_write_failures_emit_error_envelope, vlt::scan_redirect_vlt_heal_invalidation_failure_warns.

Risk

Low. The change is mechanical, the compiler checks every call site, and the outputs are pinned by vectors. The one public item removed is vlt_preflight::sha512_sri, and nothing in the workspace outside core used it.

Remaining (slice 2)

The 6 pending files. They are waiting on open PRs sbt, Mill and scala-cli support in agent, hosted and vendored modes #690, Full Gradle support in agent, hosted and vendored modes #646, Fix vendored mode replacing symlinked lockfiles (#627) #802, Fix Hatch environments being invisible to stale-install checks and VEX (#335) #700, Fix vendored Pipenv re-vendor to a newer patch (#769) #825 and Fix yarn berry project gates drifting between modes (#628, #629) #657.
A sha512_hex_of helper for the berry/maven hex sha512 sites.
The validator rename (sha256_hex → parse_sha256_hex), which touches vex/discover/maven.rs (Full Gradle support in agent, hosted and vendored modes #646).
apply::is_valid_blob_hash.

🤖 Generated with Claude Code

https://claude.ai/code/session_018qs9ueQm9g96AmuZfDt3Cw

Generated by Claude Code

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

Add sha256_hex_of, sha1_hex_of, sha512_base64_of and sha512_sri_of to utils::digest and move every inline sha256, sha1 and sha512 SRI computation in production files no open PR changes onto them. Delete the private copies they replace: ledger_snapshots::sha256_hex, vlt_preflight::sha512_sri, nuget_feed::content_hash, the npm_pack and bun_lock SRI blocks, and api::client::is_valid_sha256_hex (now digest::is_hex(s, 64)). No user-visible change: every helper produces the same lowercase hex or padded base64 the inline copies did, pinned by known vectors. A ratchet test fails on any new inline digest in production code and lists the six files left for slice 2. Refs #706. Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) · 2026-10-05T14:18:49Z

BugBot review

Generated by Claude Code

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

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

Mikola Lysenko (mikolalysenko) · 2026-10-05T15:42:50Z

Burn-down agent: labeled Ready for review.

Head: 58a6d1cd8ddfaec7bade8e97e2f868c78436f30d
CI: 488/488 check runs green (success/skipped) on this head; mergeable clean
Bugbot: reviewed 58a6d1c, no new issues; no open threads
Reviewer focus: refactor slice 1 of Compute sha256, sha1 and sha512-SRI digests through utils::digest instead of inline copies #706: sha256/sha1/SRI digest computations moved into utils::digest; Compute sha256, sha1 and sha512-SRI digests through utils::digest instead of inline copies #706 stays open for slice 2

Generated by Claude Code

At capacity (3 open). New p1 #872 tops the queue but waits on #865. Assisted-by: Claude Code:claude-opus-5-5

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

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)

main is red: #646 added inline sha1/sha256 calls that #865's production_digests_go_through_the_helpers guard rejects. This ports the fix from #878 so this PR's coverage job can go green. It becomes a no-op once #878 lands. Assisted-by: Claude Code:claude-opus-5-5

main has been red since #865 added a check that production code computes digests through utils::digest, while #646's Gradle code still hashes inline. Port #878's change so this PR's coverage and test-release go green; it no-ops once #878 lands on main. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016uQyhodCtdJGrKaD7AAV1n

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

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)

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

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 65112a8)

* Start fix for #769 Assisted-by: Claude Code:claude-opus-5-5 * Re-vendor Pipenv locks to a newer patch A Pipenv project vendored at one patch never moved to a newer patch for the same package: the re-vendor refused with pypi_pipenv_source_already_exists and the run exited 1, although the dry run previewed would_revendor. When the vendor ledger records the Pipfile.lock entry the older patch wrote, and that entry is unchanged, it is now rewired in place to the new wheel. The record carries the older entry's pre-vendor registry original forward, so vendor --revert still restores the user's pin. Without that record, or after an edit, it still refuses as before. Refs #769 Assisted-by: Claude Code:claude-opus-5-5 * Re-vendor PyPI installs from an older patch When a venv was installed from the vendored wheel of an older patch (pipenv sync after vendoring), re-vendoring to a newer patch skipped the package as package_not_installed and exited 1: the installed files are the old patch's bytes, so they failed the new patch's installed-variant check. When the vendor ledger holds exactly this package at an older patch uuid, such an install is now treated like a lock-only checkout: the pristine wheel comes from the lock, registry or patch service, and the package is re-vendored. The service download plan makes the same call. Fixes #769 Assisted-by: Claude Code:claude-opus-5-5 * Keep the ledger-less Pipenv wrappers test-only check_target_guards and wire_pipenv now have no production caller (the vendor flow passes the ledger through the _superseding variants), so clippy flagged them as dead code. Compile them for tests only and point the docs at the variants production uses. Refs #769 Assisted-by: Claude Code:claude-opus-5-5 * Port #851's vex alias test fix Main has been red since 4646693 (#605): two commands::vex_consumed tests built for #738 assume the name-keyed resolver never returns npm-aliased copies, which #605 changed. This is the same test-only change as #851 and becomes a no-op once that lands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VSXCFoPbraq7rNKJpXEP2n * Port #878's Gradle digest routing Main is red since 1714299 (#865): its production_digests_go_through_the_helpers guard flags the inline digests that #646 added in gradle_cache.rs, jvm_jar.rs and sidecars/maven.rs. This is the same change as #878 and becomes a no-op once that lands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VSXCFoPbraq7rNKJpXEP2n --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #410 Assisted-by: Claude Code:claude-opus-5-5 * Fix pip rollback refusing all-hosted requirements Hosted rollback, remove and the hosted-to-vendored takeover refused a requirements.txt in which every requirement was a hosted pin (a lone `six==1.16.0`, or one beside `-e .`). They couldn't tell whether the original line used pip's hash-checking mode, so the only way back was version control. The restore now counts an editable line as unhashed evidence (pip refuses editables in hash-checking mode). When no other line settles the mode, it reads the hosted line itself: the rewriter writes `--hash` only into an already hashed file and otherwise pins by the url's `#sha256=` fragment. With nothing else in the file to conflict with, either restored form installs. Fixes #410 Assisted-by: Claude Code:claude-opus-5-5 * Update restore golden for sole-pin requirements The golden test asserted that a requirements.txt holding only the hosted pin is refused as ambiguous, which is the #410 bug. It now asserts that both the unhashed and hashed sole-pin files round-trip, and keeps the mixed hashed/unhashed refusal. Refs #410 Assisted-by: Claude Code:claude-opus-5-5 * Fix vex alias tests broken by store-copy merge #605 taught the name-keyed npm resolver to probe bundled store trees, so it now finds aliased copies (node_modules/lp) and a nested host's store peers itself. Two vex_consumed tests from #738 assumed that set never held aliases, so main's CI went red after both merged. The tests now feed the alias-free set explicitly to keep covering alias expansion, and also check the resolver's own set reaches the same copies with no duplicates. No production code changes. Assisted-by: Claude Code:claude-opus-5-5 (cherry picked from commit 40dac07) * Route Gradle digests through utils::digest 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) --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #831 Assisted-by: Claude Code:claude-opus-5-5 * Keep vendored npm tarballs out of .gitignore Vendoring into a yarn classic, yarn berry, npm, pnpm or bun project wrote .socket/vendor/npm/<uuid>/<pkg>.tgz without checking whether git would commit it. Under Node.gitignore's `*.tgz`, or a `vendor/` or `.socket/` rule, the scan reported success, the commit dropped the tarball, and every fresh checkout's install failed. The shared tarball staging now refuses with vendor_artifact_gitignored before writing anything when a rule ignores the uuid dir itself. After writing, it adds <uuid>/.gitignore (re-including the tarball against rules like `*.tgz`) and .gitattributes, as vlt already does, and checks the written paths again. Refs #831 Assisted-by: Claude Code:claude-opus-5-5 * Fail vendor --check on unledgered lock references When the vendor ledger and manifest were ignored or dropped from a commit, `vendor --check` found nothing to compare and exited 0, while the lockfile still pointed at .socket/vendor/<eco>/<uuid>/ and every fresh install failed. The check now reads the lockfile references (the same scan repair uses) and reports each one no ledger entry owns as vendor_ledger_missing. Refs #831 Assisted-by: Claude Code:claude-opus-5-5 * Document the vendored tarball's uuid .gitignore The contract's vendoring table now says every npm-family tarball flavor writes <uuid>/.gitignore and .gitattributes next to the tarball, and refuses vendor_artifact_gitignored when git would still drop it. Refs #831 Assisted-by: Claude Code:claude-opus-5-5 * Keep patch uuids out of vendor --check messages CodeQL flagged the new unledgered-reference message for printing the patch uuid. The human line and error detail now name only the ecosystem; the JSON event still carries the uuid and path as repair's event does. Refs #831 Assisted-by: Claude Code:claude-opus-5-5 * Port #851: fix vex alias tests broken by the store-copy merge main's #605 made the name-keyed npm resolver reach alias and peer copies itself, which broke two vex_consumed tests that assumed an alias-blind resolver. Same change as #851, ported so this PR's CI runs green against the current base; it no-ops once #851 lands. Refs #831 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FMZyKmgYNAridSR5eqv999 * Refuse a gitignored vendor dir before the hosted takeover The tarball gitignore refusal only ran inside stage_patch_pack, which the hosted->vendored takeover reaches after restore_upstream has already removed the hosted pin. In a hosted project that ignores .socket/, vendoring then restored the registry entry and refused, leaving the package patched in neither mode. The npm takeover preflight now runs the same uuid-dir probe before the restore, as vlt's preflight already does. Refs #831 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FMZyKmgYNAridSR5eqv999 * Port #878: route Gradle digests through utils::digest main's #865 added a test that fails when production code computes digests inline; the Gradle cache, JVM jar and Maven sidecar code landed with inline sha1/sha256 calls, so main's coverage and test-release jobs fail production_digests_go_through_the_helpers. Same change as #878, ported so this PR's CI runs green against the current base; it no-ops once #878 lands. Refs #831 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FMZyKmgYNAridSR5eqv999 --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #364 Assisted-by: Claude Code:claude-opus-5-5 * Refuse hosted yarn classic with an offline mirror A yarn classic project that sets yarn-offline-mirror (in .yarnrc or .npmrc) had its lock rewired to the hosted tarball. Yarn looks mirror tarballs up by file name, and the hosted one has the same name as the upstream tarball already in the mirror, so every install got the unpatched bytes and failed the integrity check (or, offline, never found the patched tarball) while the scan reported success and VEX attested the patch. The hosted rewrite now leaves yarn.lock untouched in that case, warns with redirect_yarn_classic_offline_mirror and points to vendored mode, which works with a mirror. The dependency is not counted as redirected or attested. Both config files are read only beside a classic lock. Fixes #364 Assisted-by: Claude Code:claude-opus-5-5 * Keep mirrored yarn classic vendored on takeover A vendored-to-hosted takeover reverted the vendored yarn classic wiring before the hosted rewrite refused the offline mirror, leaving the package patched in neither mode. The takeover now checks the mirror first and keeps the package vendored. Adds a real-yarn e2e (yarn 1.22.22, populated mirror) showing the scan refuses, writes no attestation, and fresh installs still work online and offline. Refs #364 Assisted-by: Claude Code:claude-opus-5-5 * Document the yarn classic offline mirror refusal Refs #364 Assisted-by: Claude Code:claude-opus-5-5 * Re-bless pdm and poetry rewrite goldens These goldens hash the Debug text of the whole rewrite result, which now carries the empty refused_yarn_classic_uuids set. With that field stripped from the text, the old goldens still match every case, so only the output digests change; case keys and inputs are identical. Refs #364 Assisted-by: Claude Code:claude-opus-5-5 * Fix mirror e2e on yarn releases before 1.7 yarn 1.0 to 1.6 install nothing from an offline mirror even without socket-patch, so the fresh-install leg of the new mirror e2e failed on the yarn-classic 1.0.2 and 1.6.0 matrix legs. Those releases now pin that known limitation; the hosted refusal is still checked on every release. Refs #364 Assisted-by: Claude Code:claude-opus-5-5 * Detect a .yarnrc offline mirror written with a colon yarn 1's .yarnrc parser ends an unquoted key at ':', so `yarn-offline-mirror: ./mirror` and `yarn-offline-mirror:./mirror` configure the mirror just like `yarn-offline-mirror ./mirror`. The mirror check only split on whitespace, so either spelling slipped through and hosted mode still rewired the lock, reproducing #364. Refs #364 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016uQyhodCtdJGrKaD7AAV1n * Port vex alias test fix from #851 main has been red since #605 taught the name-keyed resolver to return npm-aliased copies, which broke two vex_consumed tests added by #738. Port #851's test update so this PR's CI goes green; it no-ops once #851 lands on main. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016uQyhodCtdJGrKaD7AAV1n * Port Gradle digest-helper fix from #878 main has been red since #865 added a check that production code computes digests through utils::digest, while #646's Gradle code still hashes inline. Port #878's change so this PR's coverage and test-release go green; it no-ops once #878 lands on main. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016uQyhodCtdJGrKaD7AAV1n --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #367 Assisted-by: Claude Code:claude-opus-5-5 * Keep a project's own bun patch when rewiring Bun Bun applies a patch from `bun patch` (package.json patchedDependencies, mirrored in bun.lock) only while the lock resolves the package to its registry name@version. Hosted and vendored mode moved that entry to a hosted URL or a vendored tarball, so every later install silently dropped the user's own patch while socket-patch reported success. Hosted mode now leaves such a package on its registry entry in both bun.lock and bun.lockb, warns redirect_bun_patched_dependency_skipped naming the key, and keeps the in-run VEX from assuming the Socket patch applied. Vendored mode refuses it with vendor_lock_entry_unsupported before any write or download. Other packages in the lock are still rewired. Fixes #367 Assisted-by: Claude Code:claude-opus-5-5 * Format the new Bun patch tests Assisted-by: Claude Code:claude-opus-5-5 * Never confirm a Bun package the user patched Bugbot review of #873 found two gaps in the bun patch guard. A text bun.lock only reached the root package.json through its workspaces section, so a lock without one never saw the patchedDependencies keys and rewired the package anyway. The manifest is now read beside either Bun lock. A package left on the registry could still be counted as switched when a sibling package-lock.json took the hosted URL, although Bun keeps installing the registry bytes. Such uuids are now recorded as refused and never confirmed. Refs #367 Assisted-by: Claude Code:claude-opus-5-5 * Keep rewrite goldens stable with the new field The refused-Bun uuid set added to RewriteResult changed the serialized and Debug output that the redirect equivalence goldens hash. The set is now left out of serialization when empty, like the other per-ecosystem uuid sets, and the two goldens that hash the Debug output (poetry, pdm) are re-blessed. Only their output digests change; every case and input digest is identical. Refs #367 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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) * Read a JSONC package.json for Bun patch keys Bun accepts comments and trailing commas in package.json. The patchedDependencies reader parsed it as strict JSON, so such a manifest yielded no keys. A bun.lockb project has no text mirror to fall back on, so the project's own bun patch could still be rewired away. The reader now strips JSONC comments and trailing commas before parsing, leaving string contents untouched. Refs #367 Assisted-by: Claude Code:claude-opus-5-5 * Skip a BOM before reading Bun patch keys A Windows-saved package.json can start with a UTF-8 byte order mark, which Bun ignores but serde_json rejects. The reader found no patchedDependencies keys in such a manifest, so a bun.lockb project could still lose its own bun patch. The mark is now stripped first, as the crate's other manifest readers do. Refs #367 Assisted-by: Claude Code:claude-opus-5-5 --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #826 Assisted-by: Claude Code:claude-opus-5-5 * Keep gem declarations sharing a line with ; A Gemfile line like `gem "a", "1"; gem "b", "2"` had its second declaration deleted when socket-patch redirected or vendored gem "a", because the rewrite replaces the whole line and the safety check did not know that `;` starts a new statement. The next frozen `bundle install` then failed. Such lines are now refused with a warning and left untouched. A declaration ending in a bare `;` (optionally followed by a comment) was refused as "continues on the next line" since #637. It is complete, so it is rewritten again, without the `;`. Fixes #826 Assisted-by: Claude Code:claude-opus-5-5 * Use the reported line shape in the ; e2e test The `;`-joined fixture had no version argument, so the old check already refused it as "unexpected tokens" and the test passed without the fix. Use `gem "x", "v"; gem "y", "v"` from #826, which the old code rewrote and lost the second gem. Assisted-by: Claude Code:claude-opus-5-5 * Port #878: route Gradle digests through helpers main is red: #646 added inline sha1/sha256 calls that #865's production_digests_go_through_the_helpers guard rejects. This ports the fix from #878 so this PR's coverage job can go green. It becomes a no-op once #878 lands. Assisted-by: Claude Code:claude-opus-5-5 --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #760, #762 Assisted-by: Claude Code:claude-opus-5-5 * Test that a Poetry/PDM lock renders once per scan Hosted scans rewrite poetry.lock and pdm.lock once per patched package, rendering and re-parsing the whole lock each time. Count the engine's whole-lock renders and require one per lock for a dozen patched packages. Both tests fail today with 12 renders. Refs #760, #762 Assisted-by: Claude Code:claude-opus-5-5 * Rewrite each Poetry/PDM lock in one pass A hosted scan rewrote poetry.lock and pdm.lock once per patched package, and every rewrite rendered and re-parsed the whole lock. A project with a dozen patches paid for a dozen full parses, which made Poetry and PDM scans 3.5-4.5x slower per package than other managers. The shared lock-splice engine now plans every package against one parsed lock, applies all the changes, renders and re-parses once, and splices each package's changed fragments into the original text. The result is checked against the rendering byte for byte. When a lock mixes line endings, a package is rewritten twice, or any check fails, the rewrite falls back to the old package-by-package path, so output and recorded edits never change. Differential tests run both paths over every Poetry and PDM lock generation, LF, CRLF and mixed, with refusals, missing packages and re-runs mixed in, and require identical text and per-package results. Fixes #760, #762 Assisted-by: Claude Code:claude-opus-5-5 * Read PDM lock_version from the parsed original The rewrite never changes [metadata] lock_version, so read it from the parse the presence probe already took instead of parsing the output. Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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 * Drop the unrelated formatting sweep Running cargo fmt over the whole workspace reformatted 117 files this PR does not otherwise touch, because main is not rustfmt-clean and CI does not check formatting. Restore those files to main and keep the diff to the Poetry/PDM rewrite and the ported digest fix. Assisted-by: Claude Code:claude-opus-5-5 --------- Co-authored-by: Claude <noreply@anthropic.com>

* Cancel superseded npm/pnpm/Pipenv PR runs npm-compatibility, pnpm-compatibility and pipenv-compatibility had no concurrency group, so every push to a PR left the previous run's full matrix (11, 26 and 6+ jobs) running to completion against a commit nobody will merge. Over the last 100 PR runs of each (about 8 hours), 52 runs were superseded while still running and spent ~445 job-minutes after the newer push landed, competing for runners with the live runs. Group PR runs per PR number with cancel-in-progress, as ci.yml and the other compatibility workflows already do. Every non-PR event gets its own group (run_id) so no main push or dispatch is ever cancelled, not even while pending behind another run in the group. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EQTUzCY6pkBLc3BNJhz9Nu * Route Gradle digests through utils::digest 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) --------- Co-authored-by: Claude <noreply@anthropic.com>

* Run pnpm install-proof as one job per Node The pnpm install-proof matrix spawned 25 single-version jobs (one per pnpm/Node pair) whose real work is ~20 s each. Most of each job was runner setup, and any one leg that never got a runner left the run red: on 2026-10-05 20/28 pnpm runs failed, every failed leg checked being an ubuntu-latest job cancelled with no runner and no log. Group the legs by Node runtime (10, 16, 24): each job installs its pnpm versions, then runs both pinned suites per version in turn with a per-version TMPDIR so the shared cache sandbox starts empty, as it did on a fresh runner. Every pnpm/Node pair still runs on every PR and main push; a failure is reported per version via ::error. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uej6tnJfjRU8NCUz2jdDG4 * Route Gradle digests through utils::digest 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) --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #915 Assisted-by: Claude Code:claude-opus-5-5 * Patch the gem Bundler loads under path.system A project that switched from vendor/bundle back to system gems (`bundle config set path.system true`, or BUNDLE_PATH__SYSTEM=true) usually still has the old gitignored vendor/bundle. The gem crawler always counted that leftover store and, because it held gems, stopped looking in the `gem env` homes. Agent apply then patched only the unused copy, and vex attested not_affected while Bundler kept loading the unpatched system gem. The crawler now works out which Bundler settings tier decides the install path (local config, then environment, then global config) and, when that tier sets a truthy path.system, skips the default vendor/bundle root so the system gem homes are crawled. path.system values now follow Bundler's own boolean coercion, so "1" or "yes" count as true too. Fixes #915 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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) * Skip env bundle path shadowed by path.system When the Bundler tier that wins sets path.system, Bundler also ignores an env BUNDLE_PATH below it or beside it. If that value named the leftover vendor/bundle, the crawler still probed it as the default root and hid the system gem homes again, so apply and vex kept targeting the unused copy. The env root is now skipped in that case too. Assisted-by: Claude Code:claude-opus-5-5 --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #908, #521 Assisted-by: Claude Code:claude-opus-5-5 * Restore berry and vlt pins from project registry Hosted rollback and remove looked up a package's version document on the default registry (npmjs or SOCKET_NPM_REGISTRY) only. On a project that installs from a mirror whose tarball URLs are off the usual path, that broke the restored lock: - yarn berry wrote a bare npm: locator, so a cold-cache install asked the mirror for a path it never serves and failed with a 404 (#908). - vlt rebuilt slot [3] as <registry>/<name>/-/<leaf>-<ver>.tgz instead of the URL the registry advertises, which vlt ci can 404 on (#521). The restore now reads the document from the registry the project resolves the package against (.yarnrc.yml npmRegistryServer, the vlt node's registry) and vlt takes slot [3] from its dist.tarball. If that registry can't be read (for example it needs credentials), the old default-registry lookup is used and upstream_registry_fallback warns. Fixes #908 Fixes #521 Assisted-by: Claude Code:claude-opus-5-5 * Name the per-registry npm cache type Keeps clippy's type_complexity lint quiet for the restore client's registry-keyed version-document cache. Assisted-by: Claude Code:claude-opus-5-5 * Keep npmScopes packages on the default lookup A scoped package in a .yarnrc.yml with an npmScopes block may resolve against its scope's registry rather than npmRegistryServer, so berry restore keeps reading its document from the default registry, as before, instead of asking a registry that may not host it. Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest main's test suite is red: the Gradle cache, jar and Maven sidecar code from #646 hashes inline, which the digest guard test from #865 forbids, so coverage and the macOS/Windows test jobs fail on every PR. This is the same change as #878, ported so this PR can go green; it no-ops once #878 lands. Assisted-by: Claude Code:claude-opus-5-5 * Serialize berry checksum tests that read SOCKET_NPM_REGISTRY The npm dist cache is now keyed by registry base, and these two tests seed it under npm_registry_base(), which reads SOCKET_NPM_REGISTRY. Serial vlt/bun tests set that variable, so when one ran in parallel the lookup key no longer matched the seeded entry and the test fetched left-pad from the other test's mock server (404). That is the test (windows-latest) failure on 48798c4. Serializing them with the env-mutating tests closes the race. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

* Bench: add gradle hosted and rescan scenarios #646 gave Gradle builds a hosted mode: scan crawls Gradle's modules-2/files-2.1 cache, pins suffixed versions in gradle.lockfile and wires the build through an owned settings script and index under .socket/gradle/. None of that was benchmarked; the maven scenarios only reach the pom.xml + ~/.m2 path. The gradle fixture is a single-project Groovy build with dependency locking (1000 locked artifacts, 25 patched direct deps), its cache under the fixture's GRADLE_USER_HOME with jar and pom in separate sha1 dirs. The Maven-coordinate generator, pom writer and maven2 grant builder are shared with the maven fixture, whose bytes are unchanged. The grant's indexUrl is https because the Gradle planner refuses anything else; scan never fetches it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Route Gradle digests through utils::digest 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) * Bench: add hatch hosted and rescan scenarios Hatch hosted mode (#680, #743) rewrites pyproject.toml and hatch.toml in place, with no lockfile, through utils::hatch::plan. No scenario exercised that rewriter: hatch.toml is a HOSTED pypi input, and a hatch project with no lock fell through every existing pypi fixture. The fixture is a lockless hatchling app. Direct deps go in [project], and a hatch.toml default env (in-project .venv) pins every patched transitive, since hosted Hatch only redirects deps a Hatch table declares. A scan rewrites both files and adds [tool.hatch.metadata] allow-direct-references. It is sized at 1000 packages / 25 patched so a scan takes about 75-85 ms. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

) * Start fix for #926 Assisted-by: Claude Code:claude-opus-5-5 * Match PyPI names in get by their PEP 503 form `socket-patch get ruamel.yaml` (or `typing_extensions`, or `Typing.Extensions`) reported "No packages matching" and exited 0 for an installed, patchable package. The package-name search only lowercased the query, but the crawler stores PyPI names in PEP 503 form (`ruamel-yaml`), so any spelling with `.`, `_` or a run of separators never matched. Users who copy a name from requirements.txt or `pip list` were told nothing could be patched. PyPI packages are now compared with both the query and the name canonicalized per PEP 503, for exact, prefix and contains matches. npm and other ecosystems keep the plain case-insensitive compare, since `_` and `.` are distinct characters in their names. Fixes #926 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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) --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #504, #947 Assisted-by: Claude Code:claude-opus-5-5 * Test Pipenv crawl never reads the system Python A Pipenv project with no Pipenv venv yet must not have the OS Python's site-packages crawled as if they were the project's: agent mode patched them in place (#504), and vendored mode tried to vendor system-only packages into Pipfile.lock and exited 1 (#947). Replace the test that pinned the global fallback for a Pipfile marker with one asserting the opposite, and add CLI scans for agent, hosted and vendored modes. Assisted-by: Claude Code:claude-opus-5-5 * Stop Pipenv projects falling back to system Python When a Pipenv project had no Pipenv venv (a fresh checkout before pipenv install, or a project that only has a plain venv/), scan read the OS Python's site-packages instead. Agent mode then patched the system Python in place and VEX attested the project as fixed (#504); vendored mode tried to vendor system-only packages and failed with a misleading 'run pipenv lock' error (#947). A Pipenv project's env is only ever the one Pipenv resolves, so an empty result there is final. Lock-only packages still come from Pipfile.lock. Fixes #504 Fixes #947 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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. Ported from #878 so CI on this PR runs against a green base; it no-ops once #878 lands on main. Assisted-by: Claude Code:claude-opus-5-5 --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #424 Assisted-by: Claude Code:claude-opus-5-5 * Add failing tests for apply failures in --json scan --mode agent --json and get --json report a failed nested apply as failed: 0 with the patch listed as added and no error text. These tests pin the expected envelope: the patch record carries action: failed, errorCode and error, and failed counts it. Refs #424 Assisted-by: Claude Code:claude-opus-5-5 * Report apply failures in scan/get --json When scan --mode agent or get downloads a patch and the in-place apply then fails, the --json output said failed: 0, listed the patch as added and carried no error, so automation reading the JSON could not tell what went wrong. Only the exit code and status hinted at it. The nested apply now hands its failures back to the caller instead of just a pass/fail flag. Each patch that failed to apply is reported as action: failed with the same errorCode/error pair that apply --json prints (apply_failed or package_not_installed), failed counts it, and applied counts only patches that really applied. A failure that no single patch explains (unreadable manifest, yarn PnP refusal, missing patch sources) is reported as a top-level errorCode/error. Fixes #424 Assisted-by: Claude Code:claude-opus-5-5 * Keep uninstalled patches as warnings in --json When one patch fails to apply, apply only warns about other patches that have no installed copy. The JSON report now matches that: those patches are reported as package_not_installed failures only when nothing else failed the run. Adds unit tests for the failure collection. Refs #424 Assisted-by: Claude Code:claude-opus-5-5 * Check composer/gem docker sync via the manifest The composer and gem docker e2e scripts checked that scan's JSON said "action": "added". In these fixtures scan's own in-place apply fails (the later apply --force patches the file), and scan --json now reports that failure on the patch record (#424). So "added" was only there because of the bug. Check instead that the patch was recorded in .socket/manifest.json, which is what "synced" means here. Refs #424 Assisted-by: Claude Code:claude-opus-5-5 * Count only patches apply really applied The --json apply failure report could blame the wrong patch and miscount applied: - a failure on one PyPI release variant was pinned on a selected sibling variant that applied fine, via a base-purl fallback; - applied was "selected minus failed", so a selected patch that was never installed (only a warning next to a real failure) still counted as applied; - get <uuid> zeroed applied whenever any other manifest patch failed, and its extra failure records had no uuid. The nested apply now also reports which package keys it patched, and the envelope counts applied from that. A failure only marks records it covers: the same purl, or an unqualified key covering its variants. Refs #424 Assisted-by: Claude Code:claude-opus-5-5 * Add the Gradle and Maven inline digests to the pending list The digest guard test (#865) fails on main. Gradle support landed with inline sha256/sha1 computations in crawlers/gradle_cache.rs, patch/jvm_jar.rs and patch/sidecars/maven.rs, and the guard's pending list doesn't name them. List them as pending so CI is green until they move onto the utils::digest helpers. Open PRs #876 and #889 add only gradle_cache.rs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HjNH36TbmyXCpJPw3EyBZB --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #956 Assisted-by: Claude Code:claude-opus-5-5 * Quote scoped names in pnpm 7/8 vendored locks Vendoring a scoped package (@scope/pkg) into a pnpm 7 (lock 5.4) or pnpm 8 (lock 6.0) project wrote `name: @scope/pkg` into the rekeyed packages entry. A bare `@` cannot start a YAML scalar, so pnpm refused the whole lock with ERR_PNPM_BROKEN_LOCKFILE: every frozen install failed after a scan that reported success, and lock-only VEX kept attesting not_affected from a lock pnpm could not read. The name is now written through the shared YAML scalar quoting, which gives `name: '@scope/pkg'`, byte-identical to what pnpm 7.33.7 and 8.15.9 serialize themselves for the same override. Tests: a byte-exact unit oracle captured from real pnpm 7/8 for @isaacs/string-locale-compare (vendor, in-sync re-run, revert), and scoped real-pnpm lifecycle legs (frozen install, moved checkout, manifest-less VEX, revert) in e2e_vendor_pnpm_build, also run in the pinned pnpm 7/8 matrix. Fixes #956. Assisted-by: Claude Code:claude-opus-5-5 * Skip scoped legacy leg on pnpm 8.0.0-8.1.0 pnpm 8.0.0 and 8.1.0 refuse their own lock for a scoped file: tarball override under --frozen-lockfile (ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY on the key they just wrote); 8.1.1 fixed it. Measured with real pnpm on Node 16: the lock pnpm itself writes fails the same way, so no vendored scoped lock can pass there. The pinned matrix keeps the unscoped leg on those versions and runs the scoped leg everywhere else. Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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. (cherry picked from commit 659ac2c) Ported from #878 so this PR's CI is green while main's digest guard test is red; it no-ops once #878 lands. Assisted-by: Claude Code:claude-opus-5-5 * Re-vendor rewrites a stale unquoted scoped name edit_packages treated a packages entry as in sync once its file: key and resolution matched, without looking at name:. A lock vendored by a release before the #956 fix still carries `name: @scope/pkg`, which pnpm 7/8 can't load, so a later vendor reported the package already vendored and left the lock broken. The in-sync check now also requires the canonical quoted name: line, so the old spelling is rewritten like any other stale wiring. The new test revendor_heals_an_unquoted_scoped_name fails without this change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UepoBazrbnBjy7HkD9YVJN --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #900 Assisted-by: Claude Code:claude-opus-5-5 * Name the real cause when vendor --check fails `vendor --check` reported every dead vendored entry as "no lockfile or config references .socket/vendor/... any more; re-run `socket-patch vendor`". In two common cases that was false and the remedy did nothing, so the CI gate stayed red for good: - Another lock (e.g. package-lock.json beside a wired yarn.lock or bun.lock) resolves the same version from the registry. The check now says the wiring is contested, names both locks, and says to delete the lock the project does not install from. - The dependency left the lock (`npm uninstall` or an upgrade). The check now says the dependency was removed and points at `socket-patch scan --mode vendored --prune`, the command that reverts the entry. This matches scan's own hint. Discovery now keeps the refs it drops as contested, so callers can name the contesting lock. `vex`'s vendor_unwired phrase no longer claims nothing wires the artifact when the cause is a contest or a removed dependency. Fixes #900 Assisted-by: Claude Code:claude-opus-5-5 * Document vendor --check cause-specific reasons Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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) --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #974 Assisted-by: Claude Code:claude-opus-5-5 * Run the musl binary on musl hosts in npm wrapper Yarn classic ignores the `libc` field, so on Alpine it installs both the -gnu and the -musl platform package. The npm wrapper always took the first package that resolved (-gnu), whose glibc binary cannot start on musl, and then exited 1 without printing anything. Every socket-patch command failed silently in yarn classic projects on Alpine and in node:*-alpine CI images. The wrapper now detects the host libc (Node's runtime report, then the musl loader probe scripts/install.sh uses) and tries the -musl package first on musl. If a binary cannot be spawned it tries the next installed candidate, and if none can run it prints the spawn error instead of exiting silently. Fixes #974 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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 --------- Co-authored-by: Claude <noreply@anthropic.com>

…884) (#901) * Start fix for #884 Assisted-by: Claude Code:claude-opus-5-5 * Refuse hosted runs from npm/yarn/bun members A hosted scan or get run from a member of an npm, yarn (classic or berry) or Bun workspace found the member's copy of a patched package, saw no lockfile in the member directory, pinned nothing and exited 0 with "success". The package manager then installed the unpatched copy from the workspace root's lockfile, and the only hint was a warning about a missing package-lock.json. The workspace-member pre-check only knew about pnpm and cargo. It now also finds the nearest ancestor package.json whose "workspaces" list matches the member directory. If that root holds a package-lock.json, npm-shrinkwrap.json, yarn.lock, bun.lock or bun.lockb, the run is refused before anything is written with redirect_workspace_lockfile_elsewhere, and the message names the workspace root to run from. Vendored mode already refused this layout. Fixes #884 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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 * Follow nested workspaces to the outer lock A workspace root with no lockfile of its own can itself be a member of an outer workspace (yarn berry's nested worktrees), where the outer root holds the lockfile both use. The member check stopped at the inner root and let the hosted run report success with nothing pinned. It now keeps walking with the inner root as the member and refuses at the outer root. Refs #884 Assisted-by: Claude Code:claude-opus-5-5 * Stop the member walk at a nested pnpm root A pnpm workspace nested inside an outer yarn or npm workspace owns its members: pnpm installs them from the nested pnpm-lock.yaml. The member walk treated that nested root as lockless and went on to the outer root, so the refusal named the wrong directory to run from. The walk now stops at a root holding any npm-family lock (pnpm, vlt, Rush) and leaves it to the pnpm check, which names the right root. Refs #884 Assisted-by: Claude Code:claude-opus-5-5 * Refuse at the nearest workspace lock root The previous change stopped the member walk at a nested root holding a pnpm, vlt or shrinkwrap.yaml lock and left it to the pnpm check. That check only knows pnpm workspaces with pnpm-workspace.yaml or lockfile-dir, so a stray pnpm-lock.yaml there could still let a hosted run from the member report success with nothing pinned. The pnpm check now runs first, so a pnpm workspace still gets its own precise message. The package.json walk then refuses at the first matching root that holds any npm-family lock, naming that root. Only a Rush root, whose locks live under common/config, ends the walk without a refusal. Refs #884 Assisted-by: Claude Code:claude-opus-5-5 * Prefer the nearer root over an outer pnpm one When a yarn or npm workspace sits inside a pnpm workspace, the member's lockfile is the nearer one. The pnpm check ran first and named the outer pnpm root, so a follow-up run from there would rewrite pnpm-lock.yaml and leave the member's real lockfile unpatched. The member check now weighs both roots and names the nearer one. When they are the same directory, pnpm's own message wins. Refs #884 Assisted-by: Claude Code:claude-opus-5-5 * Count only npm, yarn and Bun locks at roots pnpm reads only pnpm-workspace.yaml and vlt only vlt.json, so a pnpm or vlt lock sitting at a package.json "workspaces" root does not govern that root's members. Counting such a stray lock as ownership let it beat the outer pnpm workspace that really installs the member, and the refusal pointed at a directory whose run would rewrite the wrong lockfile. The workspaces walk now counts only npm, yarn and Bun locks. Roots that pnpm governs are left to the pnpm check, and when both kinds govern a member the nearer root still wins. Refs #884 Assisted-by: Claude Code:claude-opus-5-5 * Drop unrelated rustfmt churn from the #884 fix f92cb6a ran a workspace-wide cargo fmt, reformatting 118 files that the fix does not otherwise touch. That buried the real change in ~2,300 lines of formatting diff and invites merge conflicts with every other open PR. Restore those files to their merge-base versions; each was checked to be rustfmt-equivalent to its main version, so behavior is unchanged. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #701, #932 Assisted-by: Claude Code:claude-opus-5-5 * Stop hosted PyPI pinning platform-only wheels 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 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 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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) * Check the Pipenv refusal exit code without VEX 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 --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #957 Assisted-by: Claude Code:claude-opus-5-5 * Refuse quoted scoped pnpm aliases in vendored mode pnpm 9+ quotes a lock value that starts with `@`, so a scoped npm alias (`sl: npm:@scope/pkg@1.1.0`) is written as `'@scope/pkg@1.1.0'` in the importer or a dependent's snapshot. The vendored "aliased reference" refusal compared that raw value with the unquoted `name@version`, never matched, and vendoring reported success over a lock that every frozen install rejects (ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY) while VEX attested the package. Unquote importer versions and snapshot dependency values once, both in the scan and where the lock index keys them, so scoped aliases (and their peer-suffixed spellings) are refused like unscoped ones. The index-vs-scan oracle now generates the quoted spelling too. Fixes #957 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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) --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #852 Assisted-by: Claude Code:claude-opus-5-5 * Patch npm linked-store alias copies With npm 9-11's install-strategy=linked, an alias install such as "lp": "npm:left-pad@1.3.0" lives in a store entry named after the alias (node_modules/.store/lp@1.3.0-<hash>/node_modules/lp). Agent mode only looked for node_modules/left-pad inside store entries, so: - beside a plain left-pad copy, apply patched only the plain copy and exited 0, and vex attested not_affected while require('lp') still loaded unpatched code; - with only the alias installed, apply reported the package "not found on disk" and vex refused with package_not_found. The resolver now searches npm linked-store entries for alias copies the same way it searches an importer tree. The store variant fan-out used by apply, rollback and vex also probes a same-version entry under another name at its own dir. In both cases the entry's package.json stays the authority on name and version. Fixes #852 Assisted-by: Claude Code:claude-opus-5-5 * Cover linked-store alias copies in vex Adds the npm linked-store alias layout from #852 to vex's every-copy regression: an unpatched alias-named store entry must keep the purl out of the VEX document, and all copies patched must attest it. Refs #852 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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) --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #994 Assisted-by: Claude Code:claude-opus-5-5 * Follow quoted and ${VAR} requirements includes pip expands ${NAME} references and shlex-splits the options of a requirements line, so it follows `-r "dev reqs.txt"`, `-r dev\ reqs.txt`, `--requirement="dev.txt"` and `-r ${REQDIR}/dev.txt`. socket-patch kept the quotes, backslashes and ${...} in the include target, resolved it to a file that doesn't exist and skipped it silently. Lock-only scans then reported "No patches" (exit 0) while pip installed the include's unpatched pins, and the vendored planner, in-use probe, repair and lock-only VEX were blind to the same includes. include_target now reads the line the way pip's req_file.py does: comment stripped, ${NAME} expanded from the environment, then a POSIX shlex split, then the -r / --requirement option forms. The new expand_env_vars and shlex_split helpers live with the shared requirements grammar. Fixes #994 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest 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 * Quote the absolute include in the Windows test pip shlex-splits a requirements line on every OS, so an unquoted Windows path like -r C:\dir\shared.txt loses its backslashes and pip can't open it. The absolute-include refusal test wrote that unquoted form and failed on Windows once includes were read the way pip reads them. Write the path quoted, the form pip needs on Windows. The refusal it checks is unchanged. Refs #994 Assisted-by: Claude Code:claude-opus-5-5 --------- Co-authored-by: Claude <noreply@anthropic.com>

* Start fix for #964 Assisted-by: Claude Code:claude-opus-5-5 * Stop uv projects scanning the system Python A fresh uv checkout (uv.lock with no .venv synced yet, or a UV_PROJECT_ENVIRONMENT that doesn't exist yet) and a directory holding only PEP 723 script locks fell back to the global site-packages. Every OS-Python package then joined the candidate set, so a vendored scan tried to vendor packages the project never depends on and exited 1 with pypi_uv_lock_package_missing. uv only ever installs such a project into its own env, and the lock already supplies the lock-only packages, so the crawl now returns no env for it. A uv.lock shared with Poetry, PDM or Pipenv files keeps the old fallback. Fixes #964 Assisted-by: Claude Code:claude-opus-5-5 * Route Gradle digests through utils::digest main's coverage job is red: the digest guard test from #865 requires production hashing to go through the utils::digest helpers, and the Gradle code from #646 still hashes inline. This is the same change as #878, ported so this PR's CI can go green; it no-ops once #878 lands. Assisted-by: Claude Code:claude-opus-5-5 * Revert rustfmt-only churn in files this fix doesn't touch 661c117 ran `cargo fmt --all`, which reformatted 118 files the uv fix never changes. main isn't rustfmt-clean and CI doesn't check formatting, so the sweep adds nothing. It also hides the real change and conflicts with every other open PR that touches those files. Each reverted file is byte-identical to rustfmt's output on the merge-base version, so this drops formatting only. The six files that carry the fix and the ported #878 change keep their formatting. Co-Authored-By: Claude <noreply@anthropic.com> * Drop stale digest pending-list entries Merging main brought in #955's PENDING_INLINE_DIGESTS entries for gradle_cache.rs, jvm_jar.rs and sidecars/maven.rs, but #690 had already moved those files onto the utils::digest helpers. The guard fails on stale entries, so coverage, test and test-release are red on main and on this PR. This is the same change as #1016, ported so this PR's CI can go green; it no-ops once #1016 lands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012H7zqyRTeMzzAxit6xfV6r --------- Co-authored-by: socket-patch agent <noreply@anthropic.com>

Start refactor for #706

548501f

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

Mikola Lysenko (mikolalysenko) added refactor Structural change: duplicated code or logic, missing abstraction, layering, dead code arch-refactor PR opened by the scheduled architecture refactor routine labels Oct 5, 2026

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 5, 2026

Compute sha256, sha1 and sha512-SRI digests through utils::digest instead of inline copies #706

Open

4 tasks

Mikola Lysenko (mikolalysenko) marked this pull request as ready for review October 5, 2026 14:18

Mikola Lysenko (mikolalysenko) pushed a commit that referenced this pull request Oct 5, 2026

refactor: record #850, open #865 (#706 slice 1)

e235753

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

cursor Bot reviewed Oct 5, 2026

View reviewed changes

Tanmay Singla (Tanmay182003) approved these changes Oct 5, 2026

View reviewed changes

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

This was referenced Oct 5, 2026

Move the vendoring-service client out of api/client.rs into its own submodule #871

Open

Read the go.mod module directive through go_mod_edit (#781) #870

Merged

Mikola Lysenko (mikolalysenko) pushed a commit that referenced this pull request Oct 5, 2026

refactor: re-rank queue, #872 first

5d93afb

At capacity (3 open). New p1 #872 tops the queue but waits on #865. Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) merged commit 1714299 into main Oct 5, 2026
489 checks passed

Mikola Lysenko (mikolalysenko) deleted the arch-refactor/706-digest-helpers branch October 5, 2026 17:29

Mikola Lysenko (mikolalysenko) pushed a commit that referenced this pull request Oct 5, 2026

refactor: record #865 merge (#706 slice 1)

e73058c

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

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 5, 2026

Route Gradle digests through utils::digest #878

Closed

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 5, 2026

Fix pip rollback refusing all-hosted requirements (#410) #827

Merged

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 5, 2026

Fix gem rewrite deleting a ;-joined declaration (#826) #875

Merged

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 5, 2026

Fix hosted yarn classic with an offline mirror (#364) #839

Merged

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 5, 2026

Fix per-patch Poetry/PDM lock re-parse (#760, #762) #877

Merged

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 5, 2026

Fix gem takeover un-hosting a grouped gem (#775) #776

Merged

Mikola Lysenko (mikolalysenko) mentioned this pull request Oct 7, 2026

Fix hosted PyPI pinning platform-only wheels (#701, #932) #984

Merged

Navigation Menu

Repository navigation

Compute sha256, sha1 and SRI digests through utils::digest (#706) - #865

Compute sha256, sha1 and SRI digests through utils::digest (#706)#865
Mikola Lysenko (mikolalysenko) merged 2 commits into
mainfrom
arch-refactor/706-digest-helpers

Mikola Lysenko (mikolalysenko) commented Oct 5, 2026 •

edited

Loading

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 5, 2026

Uh oh!

cursor Bot left a comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 5, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 5, 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

Summary

Why

What changed

Deleted (git diff --stat)

Behavior

Tests

Risk

Remaining (slice 2)

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 5, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 5, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Mikola Lysenko (mikolalysenko) commented Oct 5, 2026 •

edited

Loading

Deleted (`git diff --stat`)