Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Hosted scan on a pnpm workspace with `sharedWorkspaceLockfile: false` ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing

Chiusa
  • Qualcosa non va?
#492 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@mikolalysenko ci sta già lavorando.

Dal 7/10/2026.

  • #1007 di @mikolalysenko — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
build-system, cli, devtools

Direzione di ricerca

Start in crates/socket-patch-core/src/hosted/engine.rs at read_candidate_files and inspect crates/socket-patch-core/src/formats/pnpm/hosted.rs around redirect_pnpm_entry_not_found. Run the e2e_redirect_pnpm_build.rs harness against the sharedWorkspaceLockfile=false reproduction. Done means member pnpm-lock.yaml files are handled with the root workspace trust edit, or the scan fails closed instead of reporting success with no redirects.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

agent:triaged bug bughunt pm:pnpm priority:p1

[agent] Found by the scheduled pnpm bug-hunt routine (ledger #303).

Summary

With sharedWorkspaceLockfile: false (shared-workspace-lockfile=false in .npmrc on older majors), pnpm writes one pnpm-lock.yaml per workspace package (packages/a/pnpm-lock.yaml, packages/b/pnpm-lock.yaml, …). The root pnpm-lock.yaml covers only the root importer, and is often just importers: .: {}.

scan --mode hosted from the workspace root finds the vulnerable package in node_modules, then reads only the root lock (plus the Rush locks when rush.json exists). The member locks that pnpm actually installs from are never opened. The run ends with exit 0, status: success, redirect.redirected: 0, rewrittenFiles: [], and one redirect_pnpm_entry_not_found warning ("no resolution for [email protected]"). Every package in the workspace keeps installing the unpatched registry tarball.

Impact

  • Hosted mode silently does nothing on this documented pnpm layout. success / exit 0 tells CI and users the project is patched when no lock was changed.
  • VEX stays honest: with nothing pinned, vex finds nothing to attest. So the failure is "unpatched, but reported as a successful hosted scan", not a false attestation.
  • The obvious workaround fails on pnpm 11+. Running scan --mode hosted --cwd packages/a does pin packages/a/pnpm-lock.yaml, but it also creates packages/a/pnpm-workspace.yaml (packages: ['.'] + trustLockfile: true). That turns the member into a nested workspace root, and pnpm ignores the file when installing from the real root. A fresh pnpm install --frozen-lockfile from the root on pnpm 12.8.1 then fails with ERR_PNPM_TARBALL_URL_MISMATCH.
  • Vendored mode on the same layout refuses loudly (vendor_lock_entry_not_found, partialFailure, exit 1), which is acceptable fail-closed behaviour.

Repro

mkdir -p ws/packages/a ws/packages/b && cd ws
echo '{"name":"root","version":"0.0.0","private":true}' > package.json
echo '{"name":"a","version":"1.0.0","dependencies":{"is-number":"7.0.0"}}' > packages/a/package.json
echo '{"name":"b","version":"1.0.0","dependencies":{"to-regex-range":"5.0.1"}}' > packages/b/package.json   # [email protected] transitively
printf "packages:\n  - 'packages/*'\nsharedWorkspaceLockfile: false\n" > pnpm-workspace.yaml
echo 'shared-workspace-lockfile=false' > .npmrc        # pnpm <= 10 reads this
pnpm install
ls pnpm-lock.yaml packages/*/pnpm-lock.yaml           # three locks; the root one is `importers: .: {}`
socket-patch scan --mode hosted --json --yes ...      # patch for pkg:npm/[email protected] is available
#  status: success, exit 0, redirect.redirected: 0, rewrittenFiles: [],
#  warnings: [{code: redirect_pnpm_entry_not_found, detail: "no resolution for [email protected]"}]
grep -c 'tarball:' packages/*/pnpm-lock.yaml           # 0 everywhere
# fresh checkout + pnpm install --frozen-lockfile -> both a and b load the upstream bytes

(I ran this against a local mock of the patch API: batch / by-package / package grant / view / hosted tarball, with SOCKET_PATCH_SERVER_URL and SOCKET_NPM_REGISTRY pointed at it, the same harness as the repo's e2e_redirect_pnpm_build.rs. The oracle is a marker prepended to is-number/index.js.)

Expected vs actual

  • Expected: docs/ecosystems.md (npm hosted-mode notes) says pnpm "workspaces … are handled. Every matching package instance is rewritten; an unsupported instance prevents confirming that dependency across the lockfile set." A pnpm workspace's lockfile set includes its per-package locks when sharedWorkspaceLockfile is false, so each packages/*/pnpm-lock.yaml that resolves the package should be pinned, with trustLockfile going into the root pnpm-workspace.yaml. At minimum, the run should fail closed (partialFailure / non-zero, as vendored does) instead of reporting success.
  • Actual: only the root lock is read, nothing is rewritten, and the status is success, exit 0.

Matrix (Linux, main 61cfb9b)

OS pnpm lock hosted from the workspace root vendored from the root
Linux 8.15.9 6.0 fail (success, 0 redirected) not run
Linux 9.15.9 9.0 fail (2/2) refuses vendor_lock_entry_not_found (OK)
Linux 10.34.5 9.0 fail refuses (OK)
Linux 11.28.3 9.0 fail refuses (OK)
Linux 12.8.1 9.0 fail (2/2) refuses (OK)
Linux 12.8.1 9.0 workaround --cwd packages/a: lock pinned, but the root frozen install fails with ERR_PNPM_TARBALL_URL_MISMATCH

Control: the same workspace with the default shared lock is redirected, installs patched bytes in both members, and rolls back byte for byte (passes on 9.15.9 / 10.34.5 / 11.28.3 / 12.8.1). macOS and Windows weren't probed, but the code path is OS-independent.

Not bisected. The 4.0.0 release can't be driven against the v5-shaped mock, and the candidate-file list has never included member locks.

Suspect code

  • crates/socket-patch-core/src/hosted/engine.rs:404 (read_candidate_files): it reads REDIRECT_CANDIDATE_FILES (root pnpm-lock.yaml), Cargo members, Python locks and the Rush locks (:449, rush_repo), but it never expands the pnpm-workspace.yaml packages: globs into per-member pnpm-lock.yaml keys. The comment there notes that the pnpm rewriter is already basename-generalized for nested keys, so adding member locks (and pointing the trust edit at the root workspace file) looks like the shape of a fix.
  • crates/socket-patch-core/src/formats/pnpm/hosted.rs:393: redirect_pnpm_entry_not_found is a warning only, so the miss doesn't affect the status.
Lingua principale
Rust
Stelle
8
Fork
0
Merge medio
19h 21m
PR unite (30g)
421

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di SocketDev/socket-patch

Tutte le issue di SocketDev/socket-patch

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.