Vendored yarn berry misses a parent-scoped user `resolutions` entry (`pkg-a/left-pad`), reports success, and every `yarn install --immutable` fails YN0028
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ó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 73/100
Hướng nghiên cứu
Bắt đầu tại crates/socket-patch-core/src/vendor/yarn_berry_lock.rs, ở resolutions_gate, và so sánh cách xử lý selector với resolution_selector_target() trong cùng tệp. Kiểm tra cách gate xử lý selector giới hạn theo package cha, chẳng hạn pkg-a/left-pad. Hoàn thành khi chế độ vendored từ chối trường hợp đó với vendor_override_conflict và không ghi gì.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
[agent] Found by the scheduled Yarn Berry (2+) bug-hunt routine (ledger #305).
Summary
Vendored mode's user-override gate only recognizes resolutions selectors whose descriptor name is the target (left-pad, left-pad@^1.3.0, left-pad@npm:1.3.0). A parent-scoped selector such as "pkg-a/left-pad": "1.3.0" (or "pkg-a/left-pad@^1.3.0", or "<root-name>/left-pad") is not recognized. Vendored mode then adds its own bare "left-pad": "file:./.socket/vendor/…" pin next to the user's entry, rewrites the lock entry to the file: locator, and reports success.
Yarn applies the more specific parent-scoped resolution first, so it resolves left-pad@npm:1.3.0 for that parent, and the lock socket-patch wrote no longer matches. Every fresh yarn install --immutable fails with YN0028. A plain yarn install silently drops the vendored entry and installs the unpatched registry bytes. vex then correctly attests nothing, but scan had already reported success.
Hosted mode handles the same project correctly: it refuses with redirect_yarn_berry_resolutions_conflict and writes nothing, because it uses resolution_selector_target().
Impact
A monorepo that pins a dependency for one workspace (a common use of yarn's parent/name resolutions) gets a vendored "success" that breaks CI (--immutable), or installs unpatched code on a mutable install.
Repro (yarn 4.18.1, node-modules linker, Linux)
mkdir -p proj/packages/pkg-a && cd proj
echo '{"name":"root","private":true,"workspaces":["packages/*"],"resolutions":{"pkg-a/left-pad":"1.3.0"}}' > package.json
echo '{"name":"pkg-a","version":"1.0.0","dependencies":{"left-pad":"^1.3.0"}}' > packages/pkg-a/package.json
printf 'nodeLinker: node-modules\n' > .yarnrc.yml
yarn install # lock: "left-pad@npm:1.3.0"; package.json keeps "pkg-a/left-pad"
socket-patch scan --mode vendored --json --yes --cwd . # a [email protected] patch is available
# -> status "success", vendor.summary.applied 1
cat package.json
# "resolutions": { "pkg-a/left-pad": "1.3.0",
# "left-pad": "file:./.socket/vendor/npm/<uuid>/left-pad-1.3.0.tgz" }
rm -rf node_modules .yarn/install-state.gz && yarn install --immutable
# ➤ YN0028: -"left-pad@file:./.socket/vendor/npm/<uuid>/left-pad-1.3.0.tgz::locator=root%40workspace%3A.":
# ➤ YN0028: +"left-pad@npm:1.3.0":
# ➤ YN0028: The lockfile would have been modified by this install, which is explicitly forbidden.
yarn install && head -c 60 node_modules/left-pad/index.js # unpatched registry bytes
The patch data came from a local mock of the patch API (/v0/orgs/<org>/patches/{batch,by-package,view,package} plus the tarball route), using a patched left-pad 1.3.0 tarball with a marker prepended to index.js. It reproduced on every attempt (more than 10 runs across the cells below).
Expected vs actual
- Expected: refused with
vendor_override_conflictand nothing written. CLI_CONTRACT.md: "vendor_override_conflict… vendor (pnpm/yarn-berry): a user-authored override/resolution for the package already exists." The gate's own doc comment says "Anything else same-name still refuses". Hosted mode refuses the same selector shapes ("bare, ranged or nested", docs/testing/yarn-berry-compatibility.md). - Actual:
success. The user's entry is kept, a second conflicting pin is added, and the lock is left in a state yarn rejects.
Matrix (Linux; the Windows and macOS probes are blocked, see ledger #305)
| user selector | yarn 4.0.2 | yarn 4.12.0 | yarn 4.18.1 |
|---|---|---|---|
pkg-a/left-pad |
fail (YN0028) | fail | fail |
pkg-a/left-pad@^1.3.0 |
fail | fail | fail |
<root-name>/left-pad (app/left-pad) |
n/t | n/t | fail |
left-pad, left-pad@^1.3.0, left-pad@npm:1.3.0 |
refused (correct) | — | refused (correct) |
| hosted mode, any of the above | — | — | refused redirect_yarn_berry_resolutions_conflict (correct) |
(**/left-pad: "1.3.0" isn't a useful control: yarn 4 drops that entry from package.json on its own yarn install, before socket-patch runs.)
First bad version: not a regression. Release 4.0.0 (npm @socketsecurity/[email protected]) behaves the same way. Tested on main 045d7ec.
Suspect code
crates/socket-patch-core/src/vendor/yarn_berry_lock.rs:524-528 (resolutions_gate) derives the selector's name with split_pattern(selector), which returns the whole string pkg-a/left-pad (≠ left-pad), so the continue skips it. resolution_selector_target() in the same file (:1471), which hosted (patch/redirect/mod.rs:4058) and vex discovery already use, returns left-pad for parent/left-pad, @scope/parent/left-pad and so on. Using it here would refuse the parent-scoped forms, keeping the bare exact-version takeover (selector == name) as it is.
- Ngôn ngữ chính
- Rust
- Star
- 8
- Fork
- 1
- Merge trung bình
- 19 giờ 1 phút
- Pull request đã merge (30 ngày)
- 473
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của SocketDev/socket-patch
-
agent:triaged bug pm:go priority:p2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
SocketDev/socket-patch#1409 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bug bughunt pm:npm priority:p3 ux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
SocketDev/socket-patch#1072 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package]Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởagent:triaged bug bughunt pm:cargo priority:p2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
SocketDev/socket-patch#651 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bench perf-regression pm:nuget priority:p3
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
SocketDev/socket-patch#1425 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bench perf-regression pm:go priority:p2
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
SocketDev/socket-patch#1424 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của SocketDev/socket-patch
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
router-for-me/EasyCLIProxyAPI#406 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ai-priority/P2 bug db/oracle user-priority/P1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Sweep stale notesĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 63/100