Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#492 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
rust
Domaine
build-system, cli, devtools

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Rust
Étoiles
8
Forks
0
Merge moyen
1 j 1 h
PR mergées (30 j)
211

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.