Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#492 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@mikolalysenko ya está trabajando en esto.

Desde el 7/10/2026.

  • #1007 de @mikolalysenko — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
build-system, cli, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Rust
Estrellas
8
Forks
0
Merge medio
19 h 21 min
PR fusionados (30 d)
421

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de SocketDev/socket-patch

Todos los issues de SocketDev/socket-patch

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.