Skip to content

Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install #558

Closed
#1328
Closed
Hosted yarn classic rewrite drops the #sha1 fragment when the grant has no sha1, so yarn's cache serves stale bytes: yarn ≤1.17 silently installs the unpatched package, and yarn ≥1.19 fails every warm-cache install#558
#1328
Labels
agent:claimedagent:triagedbugSomething isn't workingbughuntFound by a scheduled package-manager bug-hunt agentcompatibilityPublic CLI/JSON, saved state, upgrades, or package-manager compatibility.pm:yarn-classicYarn classic (1.x)priority:p1v5-blockerMust resolve before v5: public interface/migration or ordinary patch-install-undo failure.

Description

@mikolalysenko
Mikola Lysenko (mikolalysenko)
opened on Oct 2, 2026

[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 left-pad@1.3.0
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


left-pad@1.3.0:
  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/socket-patch@4.0.0) 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 working
    bughuntFound by a scheduled package-manager bug-hunt agent
    pm:yarn-classicYarn classic (1.x)
    on Oct 2, 2026

  2. mikolalysenko commented on Oct 2, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 2, 2026
    CollaboratorAuthor

    [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

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 2, 2026
    CollaboratorAuthor

    [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

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 7, 2026
    CollaboratorAuthor

    [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 left-pad@1.3.0 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

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 8, 2026
    CollaboratorAuthor

    [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.
    compatibilityPublic CLI/JSON, saved state, upgrades, or package-manager compatibility.
    on Oct 9, 2026

  8. mikolalysenko commented on Oct 9, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 9, 2026
    CollaboratorAuthor

    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

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 9, 2026
    CollaboratorAuthor

    [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

    66b16b1

    Refuse yarn classic pins with unlocked deps

    1d7e1bf

    Refuse yarn classic pins with unlocked deps (#1329)

    f2866e2

  12. mikolalysenko commented on Oct 9, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 9, 2026
    CollaboratorAuthor

    [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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent:claimedagent:triagedbugSomething isn't workingbughuntFound by a scheduled package-manager bug-hunt agentcompatibilityPublic CLI/JSON, saved state, upgrades, or package-manager compatibility.pm:yarn-classicYarn classic (1.x)priority:p1v5-blockerMust resolve before v5: public interface/migration or ordinary patch-install-undo failure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions