Fix yarn berry hosted pin leaking npm auth (#404) - #465
Mikola Lysenko (mikolalysenko) wants to merge 9 commits into
Conversation
Assisted-by: Claude Code:claude-opus-5-5
Hosted mode pinned a patched yarn berry package as an npm: locator (npm:<v>::__archiveUrl=<url>). Yarn fetches npm: locators with its npm fetcher, which attaches the configured registry token (npmAuthToken, YARN_NPM_AUTH_TOKEN, npmScopes) to every scoped package request, and to every request under npmAlwaysAuth, so the token was sent to the patch server on each cold install. The lock now pins a plain tarball-URL locator (<name>@<url>). Yarn fetches it with its tarball fetcher, which sends no registry auth and builds the same cache zip, so the 10c0 checksum is unchanged and --immutable still passes. Rollback, VEX and the mode takeovers keep recognizing the old form, and the next hosted scan re-pins it. An artifact URL yarn could not fetch as a tarball is refused instead of written. Fixes #404 Assisted-by: Claude Code:claude-opus-5-5
896a700 to
e20d139
Compare
|
BugBot review Generated by Claude Code |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Lock-only discovery skipped a berry entry whose resolution is a tarball URL, so a package already pinned by hosted mode dropped out of the inventory. Treat a tarball-URL resolution under npm: descriptor keys as the registry package. Also refresh the redirect and VEX goldens and the vendor takeover test for the new pin form. WIP: yarn's hardened mode rejects this pin form (YN0078), see #465. Assisted-by: Claude Code:claude-opus-5-5
|
[agent] Blocked: needs a maintainer decision on the hosted yarn berry pin shape. The tarball-URL locator in this PR does stop the token leak, but CI's Yarn enables hardened mode automatically for GitHub Actions runs on public pull requests, and Measured options (yarn 4.12.0, fresh checkout, cold cache,
Option C is the only shape that fixes the leak and works everywhere. But hosted mode would then edit Decision needed: (1) move hosted berry to option C (I can rework this PR, since most of the detection, rollback and VEX changes carry over), (2) keep A with a warn/refuse gate plus docs, or (3) something else. WIP is pushed (5229052). The PR is back in draft with Generated by Claude Code |
|
[burn-down agent] Adding Generated by Claude Code |
Assisted-by: Claude Code:claude-opus-5-5
|
[agent]
No fix exists yet. The robust fix would be to make the test's request-count assertion independent of wall-clock latency, which belongs in its own PR. I'll re-run the macOS job once when the rest of this workflow finishes (GitHub refuses a job re-run while the run is still in progress).
Generated by Claude Code |
Option C seems like the best choice, leaking auth tokens is not really acceptable. However we should avoid unnecessary package.json edits if we can avoid it. These changes should only be used if we are in yarn. If we do see a yarn project we should aslo default assume they may be running in hardened mode since we can't easily check otherwise. See if you can rework this and keep things working similarly for other versions of yarn. It sucks that yarn is so complicated. |
|
[agent] Thanks, reworking to option C. I checked the shape with real yarn 4.12 (fresh checkout, cold cache,
Scope:
I'll push in steps and keep the status block current. Generated by Claude Code |
The tarball-URL pin stopped the registry token leak, but yarn's hardened mode (on by default for public pull request CI) rejects a tarball resolution under an npm: lock key (YN0078), breaking installs. Hosted mode now pins a yarn berry package the way yarn itself does for a root resolutions entry: package.json routes each locked descriptor (name@npm:<range>) to the hosted tarball, and the lock entry is re-keyed name@<url>, moved to yarn's sort order. Only that package's descriptors move; other versions and other files stay untouched. Rollback rebuilds the original key from those selectors and removes them. A user-authored resolutions entry for the package, a missing manifest, or a builtin patch: entry wrapping the same descriptor refuse the pin instead of overwriting anything. Other npm flavors are unchanged; package.json is only read beside a yarn berry lock. Assisted-by: Claude Code:claude-opus-5-5
Lock-only inventory now keeps a berry entry keyed by its hosted tarball, so already-pinned packages stay visible to later scans. The yarn berry redirect goldens gain a root package.json and expect the resolutions selectors plus the re-keyed entry; the VEX discovery golden, the vendor takeover test and the docs, CLI contract and changelog describe the new pin shape and its refusals. Assisted-by: Claude Code:claude-opus-5-5
Assisted-by: Claude Code:claude-opus-5-5
|
BugBot review Generated by Claude Code |
A yarn.lock entry already keyed by a tarball URL is now only treated as ours when it points at the patch host or names the exact artifact. A mirror tarball of the same version is left alone and refused as a user resolution instead of being re-pinned. VEX discovery no longer reports a hosted patch from a URL-keyed lock entry unless package.json still routes the package there. A lock that lost its resolutions entry is flagged as orphaned rather than counted as patched, and a resolutions value on its own does not confirm a redirect either. The orphan refusal now tells users to restore yarn.lock and package.json from version control, or delete the entry and reinstall. Assisted-by: Claude Code:claude-opus-5-5
|
BugBot review Generated by Claude Code |
The real-yarn berry suites run on CRLF files on Windows, as yarn writes them there. The new check that the lock entry is keyed by the hosted tarball expected an LF right after the key, so it failed on every Windows run even though the lock was rewritten correctly. The check now compares whole lines with the CR stripped. Assisted-by: Claude Code:claude-opus-5-5
|
BugBot review Generated by Claude Code |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit f44ebc6. Configure here.
Mikola Lysenko (mikolalysenko)
added
the
Ready for review
|
Burn-down agent: ready for review at
Generated by Claude Code |
This branch has not been deployed
2 participants
LLM Description written by Claude Code:claude-opus-5-5
Fixes #404
Root cause
On yarn berry, hosted mode pinned a patched package by rewriting its lock
entry's resolution to
<name>@npm:<v>::__archiveUrl=<hosted tgz>. That isstill an
npm:locator, so yarn fetches it with its npm fetcher. The npmfetcher attaches the configured registry credentials (
npmAuthToken,YARN_NPM_AUTH_TOKEN,npmScopes.*.npmAuthToken) to every scoped package'srequest, and to every request under
npmAlwaysAuth: true. Those requests goto the patch host, so the registry token was sent there on every cold install.
Fix: pin the way yarn does for a root
resolutionsentryThis follows the maintainer's decision on
option C.
A tarball locator under the untouched
npm:key (the first version of thisPR) stops the leak, but yarn's hardened mode rejects it with
YN0078.Yarn turns hardened mode on by itself for public-PR CI, so hosted mode now
assumes every berry project may run hardened. For each patched package:
package.json: one descriptor-specific selector per range the lock entrycarries, routed to the hosted tarball, e.g.
"resolutions": {"left-pad@npm:^1.3.0": "https://patch.socket.dev/…/left-pad-1.3.0.tgz"}.This is the minimal edit. Other locked versions of the same package and every
other file are untouched.
yarn.lock: only that entry is re-keyed"left-pad@<url>":, with thesame URL as its
resolution:and the patched10c0checksum.version:,dependencies:and every dependent's descriptors stay byte-identical. Theentry moves to yarn's key order, because yarn sorts entries and
--immutablewould otherwise rewrite the lock.
This is exactly what yarn writes itself, verified with real yarn. Yarn then
uses its tarball fetcher, which sends no registry auth and builds the same
cache zip.
Scope and safety:
package.jsonis read only beside a berryyarn.lock,and the memory host fetches it only there. Yarn classic, npm, pnpm, bun and
vlt are unchanged.
redirect_yarn_berry_resolutions_conflict: a user-authoredresolutionsentry for the package (bare, ranged or nested). It is never overwritten.
redirect_yarn_berry_manifest_missing: no rootpackage.jsonobject.redirect_yarn_berry_shared_descriptor: yarn's builtinpatch:entries(
resolve,typescript,fsevents) wrap the same descriptor, so pinningit would change that entry too.
redirect_yarn_berry_artifact_url_unsupported: a URL yarn can't fetch asa tarball.
restores the registry resolution and checksum, moves the entry back, and
drops the selectors. An emptied
resolutionstable is removed.::__archiveUrl=) isstill recognized by rollback, VEX and the takeovers, and the next hosted scan
re-pins it.
(Bugbot's finding on the first version). Vendored ⇄ hosted takeovers work in
both directions.
Evidence
Measured with real yarn 4.12.0 (fresh checkout, cold cache,
YARN_NPM_AUTH_TOKEN+npmAlwaysAuth, logging tarball server):--immutablenpm:…::__archiveUrl=(main)npm:key (first version of this PR)resolutionsselector + URL-keyed entry (this PR)A project locking
is-number@6.0.0(patched) andis-number@7.0.0kept the7.0.0 registry entry.
Per-issue checklist (#404)
stability, re-pin on a new uuid, legacy migration, and every refusal. These
live in
patch/redirect/mod.rs; the shape tests fail onmain.patch:package (resolve) is now left untouched,with both reasons named.
byte-exact,
resolutionsdropped), and legacy rollback + re-pin.e2e_redirect_yarn_berry_buildruns the freshinstall --immutable --check-cachein hardened mode(
YARN_ENABLE_HARDENED_MODE) with a registry token configured, and assertsthe patch host got no
Authorizationheader. With the same env, the firstversion of this PR fails with YN0078.
Local runs
-D warnings: clean.socket-patch-core: 4714 lib tests pass plus all integration tests,including the regenerated redirect and VEX goldens.
in_process_rollback_hosted/vendored, in_process_scan, e2e_vex_lockfile,
hosted_memory_*, and the covgap suites for scan, rollback, vendor and vex.
SOCKET_PATCH_YARN_E2E_REQUIRED=1: redirect, vendor,pnpm-linker and workspaces suites, 53/53.
because the sandbox runs as root, and fail the same way on
main.mode_migration_npm's two berry legs can't reach the real registry fromthis sandbox (TLS through the proxy), so CI runs them.
Follow-ups
yarn install --immutablefails YN0028 #368 (yarn builtin-patch:packages) now gets a clear refusal instead of asilent no-op. Patching those packages in hosted mode remains open.
Note
Medium Risk
Changes hosted-mode lockfile and package.json wiring for Yarn Berry across redirect, rollback, discovery, and takeovers; behavior is well-tested but affects CI install paths.
Overview
Fixes #404: hosted Yarn Berry no longer uses an
npm:locator with::__archiveUrl=, which caused Yarn’s npm fetcher to send registry tokens (npmAuthToken,YARN_NPM_AUTH_TOKEN,npmAlwaysAuth) to the patch host.Hosted redirect now matches Yarn’s root
resolutionspattern:package.jsongets descriptor selectors (e.g."left-pad@npm:^1.3.0") pointing at the hosted tarball, andyarn.lockre-keys the entry to"<name>@<url>"with a plain tarballresolution:and the patched10c0checksum. Re-keyed entries are re-sorted when the lock was already in Yarn order soyarn install --immutableand hardened mode (YN0078) stay valid.Rollback/remove, lock inventory, and takeover detection understand the new shape and legacy
::__archiveUrl=pins (re-pinned on the next hosted scan). New fail-closed warnings cover conflicting userresolutions, missing manifest, sharedpatch:descriptors, and unsupported artifact URLs. Docs, fixtures, and e2e tests assert noAuthorizationon patch-host tarball fetches with tokens configured.Reviewed by Cursor Bugbot for commit f44ebc6. Configure here.
Generated by Claude Code