Description

Mikola Lysenko (mikolalysenko)

opened on Oct 2, 2026

Issue body actions

[agent] Found by the scheduled Yarn classic (1.x) bug-hunt routine (ledger #304).

Summary

In hosted mode, rewrite_yarn_classic writes resolved "<hosted-url>#<sha1>" only when the granted tarball artifact carries integrity.sha1. When the grant has only sha512, it writes a resolved URL with no fragment, adds the new integrity line, and reports success. The repo's own hosted npm-family fixtures use that sha512-only shape, for example covgap_commands_scan_hosted.rs:1339 and e2e_redirect_bun_build.rs:809.

Yarn classic names its cache slot npm-<name>-<version>-<fragment>[-integrity]. With no fragment, the hosted entry lands in npm-left-pad-1.3.0-integrity. That's the same slot as:

• any fragmentless upstream entry of the same name and version in the shared per-user cache (another project, a private registry whose resolved has no #sha1), and
• an earlier sha1-less hosted patch of the same version (a superseding patch, which has a different URL but the same slot).

The URL plays no part in the cache key, so yarn reuses whatever bytes are already in that slot:

• yarn 1.0.2 – 1.17.3: yarn install --frozen-lockfile exits 0 and installs the cached unpatched (or superseded) bytes, even though the lock pins the patched integrity. scan reported redirected: 1.
• yarn 1.19.0 – 1.22.22: every warm-cache install fails with error Incorrect integrity when fetching from the cache for "left-pad" … Run yarn cache clean.

vex does notice the unpatched tree (patch omitted from VEX: the patched files still hold the original content), so this isn't a false attestation. But the install itself silently runs the vulnerable code, or breaks.

Impact

On yarn ≤ 1.17, a hosted-patched project can reinstall unpatched code with no error. On yarn ≥ 1.19, a developer or CI machine with a warm cache can't install at all until it runs yarn cache clean. Composer already refuses this case (redirect_composer_missing_sha1 in formats/composer/hosted.rs:186). Yarn classic has no equivalent guard, and it doesn't compute the sha1 from the downloaded artifact either.

Repro (Linux, main 61cfb9b)

Mock patch API: the batch / view / patches/package routes, with the granted tarball artifact's integrity set to { "sha512": "<sri>" } only, and the hosted tgz served at http://127.0.0.1:8766/patch/npm/left-pad/1.3.0/…/left-pad-1.3.0.tgz.

# 1. Warm the cache with a fragmentless upstream entry of [email protected]
C=$(mktemp -d); A=$(mktemp -d); cd $A
echo '{"name":"app","version":"1.0.0","private":true,"dependencies":{"left-pad":"1.3.0"}}' > package.json
cat > yarn.lock <<'EOF'
# yarn lockfile v1


[email protected]:
  version "1.3.0"
  resolved "https://registry.yarnpkg.com/left-pad/-/left-pad-1.3.0.tgz"
  integrity sha512-XI5MPzVNApjAyhQzphX8BkmKsKUxD4LdyK24iZeQGinBN9yTQT3bFlCBy/aVx2HrNcqQGsdot8ghrjyrvMCoEA==
EOF
yarn install --frozen-lockfile --cache-folder $C

# 2. Hosted rewrite against a grant without sha1
socket-patch scan --mode hosted --yes --json --api-url http://127.0.0.1:8766 --org o --api-token x
grep resolved yarn.lock     # → resolved "http://127.0.0.1:8766/patch/npm/left-pad/1.3.0/…/left-pad-1.3.0.tgz"   (no #sha1)

# 3. Fresh checkout, same cache
B=$(mktemp -d); cp package.json yarn.lock $B; cd $B
yarn install --frozen-lockfile --cache-folder $C; echo exit=$?
head -1 node_modules/left-pad/index.js

Superseding-patch variant (no fragmentless upstream needed): start from a normal registry lock, run a hosted scan against grant A (no sha1), install, then run a hosted scan against grant B for the same version (different bytes, no sha1), and do a fresh frozen install with the same cache. yarn 1.10.1 exit 0 installs A's bytes; 1.22.22 fails Incorrect integrity when fetching from the cache.

Expected vs actual

• Expected: CLI_CONTRACT / docs/ecosystems.md describe the classic hosted lock as pinning the hosted URL plus #sha1 plus a recomputed integrity, and the capstone e2e header (e2e_redirect_yarn_classic_build.rs) says the same. A hosted rewrite should either always pin a fragment (computing the sha1 from the downloaded artifact when the grant lacks one) or refuse with a warning, as composer does. It must not report redirected for a lock that installs stale bytes or fails.
• Actual: the lock is rewritten without a fragment, scan exits 0 with redirected: 1 and no warning, and the next warm-cache install behaves as in the table below.

Matrix (Linux, Node 22; each cell run at least twice)

yarn	warm-cache frozen install after the sha1-less hosted rewrite
1.0.2	exit 0, unpatched
1.7.0	exit 0, unpatched
1.10.1	exit 0, unpatched (superseding variant: stale patch A)
1.17.3	exit 0, unpatched
1.19.0	exit 1, Incorrect integrity when fetching from the cache
1.21.1	exit 1, same
1.22.22	exit 1, same (superseding variant too)
any (cold cache)	patched (pass)
any, grant with sha1	patched (pass): the fragment gives a distinct cache slot

The OS doesn't matter, because the cache-key logic is yarn's own. macOS / Windows weren't probed.

First bad version

Not a regression: v4.0.0 (npm @socketsecurity/[email protected]) writes the same fragmentless resolved.

Suspect code

crates/socket-patch-core/src/patch/redirect/mod.rs:3110-3115: frag falls back to unwrap_or_default() when dep.integrity.sha1 is None, and no warning or refusal is emitted. Compare formats/composer/hosted.rs:186 (redirect_composer_missing_sha1).

Activity

1. Mikola Lysenko (mikolalysenko)

   added

   bugSomething isn't workingSomething isn't working

   bughuntFound by a scheduled package-manager bug-hunt agentFound by a scheduled package-manager bug-hunt agent

   pm:yarn-classicYarn classic (1.x)Yarn classic (1.x)

   on Oct 2, 2026
2. mikolalysenko commented on Oct 2, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 2, 2026

   CollaboratorAuthor

   More actions

   [agent] A correction to the "Expected" citation: the contract is crates/socket-patch-cli/CLI_CONTRACT.md. Its lockfile-discovery table (line 363) lists the yarn classic hosted pin as "classic integrity / #sha1, required". docs/ecosystems.md doesn't state the fragment explicitly, so please disregard that part of the citation.

   ---

   Generated by Claude Code
3. mikolalysenko commented on Oct 2, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 2, 2026

   CollaboratorAuthor

   More actions

   [agent] Triage: priority:p1 (yarn classic). Hosted rewrite_yarn_classic writes a fragmentless resolved URL when the grant carries no sha1, colliding in yarn's cache slot. Composer has an equivalent guard (redirect_composer_missing_sha1); yarn classic does not. Distinct root cause; no open PR covers it.

   ---

   Generated by Claude Code
4. Mikola Lysenko (mikolalysenko)

   added

   agent:triaged

   priority:p1

   on Oct 2, 2026
5. mikolalysenko commented on Oct 7, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 7, 2026

   CollaboratorAuthor

   More actions

   [agent] Re-triage on main 05ecc6e: still reproduces on Linux, ×2 per version, using the issue's repro (warm the cache with a fragmentless upstream [email protected] lock, then a hosted scan against a grant whose artifact integrity has only sha512).

   • The scan exits 0 with redirected: 1 and no warning. The lock gets resolved "<hosted>/left-pad-1.3.0.tgz" with no #sha1 fragment.
   • yarn 1.10.1: the warm-cache yarn install --frozen-lockfile exits 0 and installs unpatched bytes.
   • yarn 1.22.22: the warm-cache frozen install exits 1 with Incorrect integrity when fetching from the cache for "left-pad".
   • Control: the same flow with a grant that carries sha1 pins #<sha1>, and the warm-cache install is patched on both versions.

   ---

   Generated by Claude Code
6. mikolalysenko commented on Oct 8, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 8, 2026

   CollaboratorAuthor

   More actions

   [agent] Re-triage on main e2d9633 (after #1057, the yarn.lock grammar move): still reproduces, Linux, ×2 per version, same repro (warm the cache from a fragmentless upstream lock, then a hosted scan against a grant whose artifact integrity has only sha512).

   • The scan exits 0 and writes resolved "<hosted>/left-pad-1.3.0.tgz" with no #sha1 fragment and no warning.
   • yarn 1.10.1: the warm-cache install --frozen-lockfile exits 0 and installs unpatched bytes.
   • yarn 1.22.22: it exits 1 with Incorrect integrity when fetching from the cache for "left-pad".

   ---

   Generated by Claude Code
7. Mikola Lysenko (mikolalysenko)

   added

   v5-blockerMust resolve before v5: public interface/migration or ordinary patch-install-undo failure.Must resolve before v5: public interface/migration or ordinary patch-install-undo failure.

   compatibilityPublic CLI/JSON, saved state, upgrades, or package-manager compatibility.Public CLI/JSON, saved state, upgrades, or package-manager compatibility.

   on Oct 9, 2026
8. mikolalysenko commented on Oct 9, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 9, 2026

   CollaboratorAuthor

   More actions

   v5 release blocker (P1). A normal first hosted Yarn classic install with a warm cache can use upstream bytes or fail when the service supplies SHA-512 only. Fix the cache identity or the supported grant contract.

   This follows the maintainer's release scope: one normally completing CLI instance, prioritizing valid-lockfile patch/install behavior, compatibility, and actionable CLI UX.
9. mikolalysenko commented on Oct 9, 2026

   

   Mikola Lysenko (mikolalysenko)

   on Oct 9, 2026

   CollaboratorAuthor

   More actions

   [agent] Claiming for v5 blocker burn-down (shared root cause: hosted yarn classic rewrite writes a fragmentless resolved URL when the grant lacks sha1). Branch: agent/v5-yarn-classic-sha1. Claim-ID: 2026-10-09T16:42:02Z-9ea6d3
10. Mikola Lysenko (mikolalysenko)

    added

    agent:claimed

    on Oct 9, 2026
11. Mikola Lysenko (mikolalysenko)

    added 3 commits that reference this issue on Oct 9, 2026

    Pin yarn classic hosted tarballs by sha1

    This issue will close once commit 66b16b1 is merged into the 'main' branch.

    66b16b1

    Refuse yarn classic pins with unlocked deps

    This issue will close once commit 1d7e1bf is merged into the 'main' branch.

    1d7e1bf

    Refuse yarn classic pins with unlocked deps (#1329)

    This issue will close once commit f2866e2 is merged into the 'main' branch.

    f2866e2
12. mikolalysenko commented on Oct 9, 2026

    

    Mikola Lysenko (mikolalysenko)

    on Oct 9, 2026

    CollaboratorAuthor

    More actions

    [agent] Re-triage from the Yarn classic bug-hunt (ledger #304), Linux, local mock whose grant artifact integrity has only sha512. Same repro as before: warm the yarn cache from a fragmentless upstream lock, run a hosted scan, then yarn install --frozen-lockfile against the same cache.

    binary	yarn	scan	resolved written	warm-cache frozen install
    main 9ab72d4	1.10.1	exit 0, no warning	no #sha1	exit 0, unpatched bytes
    main 9ab72d4	1.22.22	exit 0, no warning	no #sha1	exit 1, Incorrect integrity when fetching from the cache
    PR #1328 head 494932e	1.10.1	exit 0	…/left-pad-1.3.0.tgz#81960ffa…	exit 0, patched
    PR #1328 head 494932e	1.22.22	exit 0	…/left-pad-1.3.0.tgz#81960ffa…	exit 0, patched

    On #1328 the control cell also passes on both releases (an upstream lock that already had a fragment, so the cache key is distinct). So #1328 fixes the repro, and main still reproduces it.

    ---

    Generated by Claude Code
13. Mikola Lysenko (mikolalysenko)

    added 2 commits that reference this issue on Oct 9, 2026

    Refuse yarn classic pins with unlocked deps (#1363)

    d13811d

    Adapt yarn classic sha1 pins to main's URL redaction and empty-range …

    224bd92
14. Mikola Lysenko (mikolalysenko)

    closed this as completedin #1328on Oct 9, 2026
15. Mikola Lysenko (mikolalysenko)

    removed

    agent:claimed

    on Oct 11, 2026

Issue actions