Vendored yarn berry misses a parent-scoped user `resolutions` entry (`pkg-a/left-pad`), reports success, and every `yarn install --immutable` fails YN0028
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
從 crates/socket-patch-core/src/vendor/yarn_berry_lock.rs 中的 resolutions_gate 開始，並將其 selector 處理方式與同一檔案中的 resolution_selector_target() 進行比較。檢查 gate 如何處理像 pkg-a/left-pad 這樣的父層範圍 selector。完成標準是：vendored 模式針對該情況以 vendor_override_conflict 拒絕，且不寫入任何內容。
由索引模型根據 Issue 內容生成。
描述
[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.
- 主要語言
- Rust
- 星號
- 8
- 分支
- 0
- 平均合併
- 1 天 7 分鐘
- 30 天內合併 PR
- 178
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
SocketDev/socket-patch 的其他 Issue
-
Hosted yarn classic pins give no berry-migration warning, so a yarn 2+ install silently drops them (vendored warns about the same trap)可能已有人在做 @mikolalysenko 今天認領。 未關閉agent:claimed agent:triaged bug bughunt pm:yarn-classic priority:p1
難度 2/5 1-3 小時 新手友好度 85/100
SocketDev/socket-patch#907 · 2 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:npm priority:p1
難度 2/5 1-3 小時 新手友好度 75/100
SocketDev/socket-patch#900 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:bundler priority:p1
難度 2/5 1-3 小時 新手友好度 85/100
SocketDev/socket-patch#896 · 1 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:pipenv priority:p1
難度 2/5 1-3 小時 新手友好度 83/100
SocketDev/socket-patch#744 · 1 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:cargo priority:p2
難度 2/5 1-3 小時 新手友好度 84/100
SocketDev/socket-patch#651 · 3 則留言 ·
維護者通常 1 天內回覆
查看 SocketDev/socket-patch 的全部 Issue
相似的 Issue
-
bug
難度 2/5 1-3 小時 新手友好度 82/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 85/100
wardian-app/Wardian#1603 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 70/100
維護者通常 2 天內回覆
-
bug
難度 1/5 1-3 小時 新手友好度 72/100
peteonrails/voxtype#844 ·
維護者通常 1 天內回覆
-
feature
難度 1/5 1 小時以內 新手友好度 85/100
維護者通常 4 天內回覆