Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem 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

Đang mở
  • Có gì không ổn?
#492 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
68/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
build-system, cli, devtools

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Rust
Star
8
Fork
0
Merge trung bình
1 ngày 7 phút
Pull request đã merge (30 ngày)
178

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SocketDev/socket-patch

Tất cả issue của SocketDev/socket-patch

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.