Bug hunt ledger: NuGet / dotnet

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled NuGet / dotnet bug-hunt routine (label pm:nuget).

Last run: 2026-10-03 11:44 UTC, main 045d7ec, release v4.0.0.

Coverage matrix

Cells: OS × SDK × mode. "warm" means the global packages folder already holds the upstream package; "sln" means the lock sits in src/<Project>/. "agent custom gpf" means globalPackagesFolder / RestorePackagesPath is set.

OS	SDK	agent	agent custom gpf	vendored (cold, root lock)	vendored warm cache	vendored sln	vendored inherited sources	hosted
Linux	6.0.428	untested	fail #397	pass	fail #352	fail #353	untested	untested
Linux	7.0.410	untested	untested	pass	fail #352	fail #353	untested	untested
Linux	8.0.131 / 8.0.425	pass (apply, rollback, remove, repair, --json, locked restore; unwritable folder fails loudly)	fail #397	pass (+ <clear/>, CPM, re-run, revert); user exact-id mapping: config tie #462	fail #352 (v5 too)	fail #353	fail #354	cold pass (suite); warm fail #352 (v5 too); sln fail #353; inherited fail #354; user exact-id mapping fail #462
Linux	9.0.318	untested	fail #397	pass	fail #352	fail #353	untested	untested
Linux	10.0.401	untested	fail #397	pass	fail #352	fail #353	untested	untested
macOS	8.0.425	untested	fail #397	pass	fail #352	fail #353	untested	untested
macOS	9.0.318	untested	fail #397	pass	fail #352	fail #353	untested	untested
Windows	8.0.425	untested	fail #397	pass	fail #352	fail #353	untested	untested
Windows	9.0.318	untested	fail #397	pass	fail #352	fail #353	untested	untested
Windows	nuget.exe 7.9 / packages.config	pass (packages/)	fail #398 (repositoryPath)	untested	untested	untested	untested	untested

Per-project lock packages.<Project>.lock.json (vendored + hosted): fail #514 (Linux 8; vendored also on ubuntu/macOS/Windows × SDK 8/10). Custom NuGetLockFilePath (vendored): fail #514 (all 3 OSes × SDK 8/10).

Vendored revert on a core.autocrlf=true checkout (vendor --revert, remove, rollback, rescan→revert): fail #537 on Linux 8/10, macOS 8 and Windows 8/10 (macOS 10 not inspected). Without autocrlf: pass. Vendored, then dotnet nuget add source (re-serialized config), then revert: pass (Linux 8). Self-closing <packageSourceMapping /> and a Newtonsoft.* prefix mapping: pass (Linux 8, vendored + hosted).

Mode takeovers (Linux 8): hosted → vendored via scan --mode vendored: fail #553 (no takeover, purl case mismatch; autocrlf on and off; http and patch.socket.dev URLs). Via vendor: pass. remove/rollback with the mixed-case purl on a hosted project: fail #553. Vendored → hosted: no NuGet takeover by design (stays vendored, patched).

Hosted with a commented-out <packageSources> or <packageSourceMapping> block (Linux 8): fail #585 (splice lands inside the comment; v4.0.0 too). Vendored with the same configs: pass. get --mode vendored over a hosted project: fail #553.

CPM with CentralPackageTransitivePinningEnabled (CentralTransitive lock entry), Linux 8: hosted pass, vendored pass.

BOM packages.lock.json, Linux 8: hosted fail #623 (exit 0, nothing wired), vendored fail #623 (apply_failed). Hosted BOM + CRLF nuget.config: pass.

Hosted unwind (remove, rollback <purl>, hosted → vendor takeover → vendor --revert), Linux 8: fail #624 (lock gets the catalog packageHash, NU1403 on every restore; since de316b4). Config side is byte-exact for LF / CRLF / BOM. Vendored remove/rollback with a lowercase purl: not_found (the inverse of #553; commented there).

Symlinked nuget.config / packages.lock.json (Linux 8): hosted pass (refuses); vendored fail, see the #627 comment (link replaced, revert never restores it; v4.0.0 too).

Also passed on Linux 8 (2026-10-03): RID lock sections, custom source key + <clear />, an existing Newtonsoft.* prefix mapping, lowercase Include, hosted/vendored re-run idempotency, --dry-run (no writes), space/unicode/& paths, CPM VersionOverride, hosted remove/rollback --offline (loud refusal, nothing written), and concurrent scans (lock_held).

Section close tags with whitespace (</packageSources >, </packageSourceMapping >), Linux 8: vendored fail #685 (duplicate section; NU1100 / NU1403; v4.0.0 too); hosted pass. Long-form <clear></clear>: hosted fail (NU1100 / NU1403), fixed by open PR #597, not filed; vendored pass. Multi-TFM with the id at two versions: hosted silently upgrades the other framework, vendored NU1102 (#593, commented). SIGKILL mid-scan then re-run (hosted + vendored): pass. Vendored repair after a deleted or tampered nupkg: pass.

Project-mode agent scan (no -g) patches unrelated cached packages and VEX attests them: fail #427 (Linux 8; v4.0.0 too).

Global mode (-g)

"default" = ~/.nuget/packages, "tool" = dotnet tool install -g (~/.dotnet/tools/.store), "user gpf" = globalPackagesFolder in the user-level NuGet.Config.

OS	SDK	scan -g default	scan -g tool	scan -g user gpf	apply/rollback/vex -g default	apply -g user gpf	hosted refusal	unwritable dir
Linux	8.0.131	pass	fail #426 (+ --tool-path)	fail #397	pass (build + byte-exact rollback)	fail #397	pass	pass (non-root user, rc 1, nothing written)
Linux	6.0.x	pass	fail #426	fail #397	untested	fail #397	untested	untested
Linux	9.0.x	pass	fail #426	fail #397	untested	fail #397	untested	untested
Linux	10.0.x	pass	fail #426	fail #397	untested	fail #397	untested	untested
macOS	8.0.x	pass	fail #426	fail #397	untested	fail #397	untested	untested
macOS	9.0.x	pass	fail #426	fail #397	untested	fail #397	untested	untested
Windows	8.0.x	pass	fail #426	fail #397	untested	fail #397	untested	untested
Windows	9.0.x	pass	fail #426	fail #397	untested	fail #397	untested	untested
Windows	10.0.x	pass	fail #426	fail #397	untested	fail #397	untested	untested

-g run from inside a vendored project (scan -g --mode agent → rollback -g): Linux 8 fail #489 (vendored: regression from #446, 551c362; hosted: pre-existing; still failing on 6cd3754). macOS / Windows untested.

Also passed on Linux 8: SOCKET_GLOBAL=1, SOCKET_GLOBAL_PREFIX, --global-prefix with spaces + unicode, and -g from inside a packages.config project (no leak).

Backlog

0. Re-check hosted <clear></clear> once PR Unify hosted NuGet routing and XML splice anchors #597 lands, and whether it covers vendored Vendored NuGet doesn't recognise a close tag with whitespace (</packageSources >, </packageSourceMapping >), so it appends a second section that NuGet ignores and every restore fails NU1100 / NU1403 while scan reports success and VEX attests #685.
1. Other valid-XML spellings in vendored: xmlns on <configuration>, </configuration >, attributes on <packageSources>.
2. NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553's case sensitivity in vex output purls and list.
3. Hosted NuGet remove / rollback / takeover restore packages.lock.json to the nuget.org catalog packageHash, which isn't NuGet's contentHash for signed packages, so every later dotnet restore fails NU1403 #624 follow-up: an unsigned-package hash path; Hosted and vendored NuGet reject a packages.lock.json with a UTF-8 BOM that dotnet restores fine: hosted skips the redirect and exits 0 success, vendored fails apply_failed #623 on Windows with a PowerShell-written lock.
4. Hosted NuGet splices the Socket source (and mapping) into a commented-out <packageSources> / <packageSourceMapping> block, so every restore fails NU1100 while scan reports success and its in-run VEX attests not_affected #585 follow-ups: a real <packageSourceMapping> after a commented one, plus hosted revert after a hand-fixed config.
5. Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 / Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462 / Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 / NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 / Vendored NuGet doesn't recognise a close tag with whitespace (</packageSources >, </packageSourceMapping >), so it appends a second section that NuGet ignores and every restore fails NU1100 / NU1403 while scan reports success and VEX attests #685 on macOS / Windows and SDK 6/9/10 (probe harness: scratch_serve + SCRATCH_SCRIPT; vendored legs need --vendor-source service; hosted unwind probes must sed the feed URL to https://patch.socket.dev). Local SDK installs beyond apt 8.0 are blocked (dotnet-install 403), so this needs a probe branch.
6. Local tools (dotnet-tools.json) in agent mode; apply -g / remove -g <purl> from a vendored project; apply/rollback/vex -g on macOS / Windows.
7. Mapping edge cases: a case-variant exact id, and two Socket patches for different ids.
8. Vendored/hosted with packages.config (windows-latest probe with nuget.exe).
9. Probe-branch cleanup: deleting branches is still blocked from the sandbox (denied again 2026-10-03 11:4x), so 5 bughunt/nuget/* branches are still on the remote and need a maintainer. No new probe branches until then.

Also passed on Linux 8 (no issue): vendored with a BOM + CRLF NuGet.Config (+ byte-exact revert), multi-TFM + RestoreLockedMode, a transitive-only patched package, rollback -g alone from a v5 vendored project (no manifest → refused, nothing touched), SIGKILL-interrupted scans (re-run converges), and vendored repair of a missing or corrupt nupkg.

Known non-bugs

• (Superseded in v5.0: hosted NuGet remove/rollback now unwind manifest-less, see Hosted NuGet remove / rollback / takeover restore packages.lock.json to the nuget.org catalog packageHash, which isn't NuGet's contentHash for signed packages, so every later dotnet restore fails NU1403 #624.) A hosted unwind probe against the http://127.0.0.1 stand-in gives manifest_not_found, because lockfile discovery only recognises https://patch.socket.dev feeds. That's a harness artifact; sed the URL first.
• Without a lockfile there's no client-side content pin (vendor_nuget_no_lockfile). The missing pin is documented. The false claim that the feed "forces" the patched copy is not; that's Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352.
• Hosted and VEX read only the project-root nuget.config / packages.lock.json (CLI_CONTRACT.md, README VEX table). Root-only scope is documented. Wiring the root config without pinning the member locks is Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353.
• Staged manifests must use sha256 git-blob hashes (64 hex). A sha1 blob is refused on purpose.
• Agent apply deletes .nupkg.metadata. That's documented, and a later restore rewrites it without reverting the patch.
• rollback with no targets drops every manifest entry and GCs the blobs (README command table), so a later remove <purl> reports not_found. That's documented.
• scan -g --mode hosted / --global-prefix --mode hosted refuse with exit 2 by design (CLI_CONTRACT.md).
• apply -g on a global tool fails loudly (rc 1, not found). The silent part is scan -g (Global scan (-g) never crawls .NET global tools (~/.dotnet/tools/.store), so a patched dotnet tool install -g package is silently left out of scan, apply and vex on every OS #426).
• A vendored NuGet.Config with CRLF gets LF-terminated inserted lines (mixed endings). NuGet parses it fine, and revert is byte-exact, so it's cosmetic.
• A partial apply (EACCES midway through a multi-file patch) leaves the earlier files patched. That's intended (apply.rs retry design). It's loud (rc 1 partialFailure), VEX omits it, and rollback restores it.
• Vendored/hosted with a self-closing <packageSourceMapping /> appends a second mapping section. NuGet merges them, so it's cosmetic.
• vex -o is --org; the output flag is -O / --output. Not a bug.
• After a drift-path (excision) vendored revert, the *→nuget.org catch-all mapping that vendor created stays in nuget.config. That's intentional (revert_config_record doc) and harmless.
• vendor -g / vendor --revert -g rewiring the cwd project is the generic vendor -g and vendor --revert -g still rewire the current project: on vlt, --revert -g silently unpatches a vendored project (the #446 fix skipped vendor.rs) #498, not NuGet-specific.
• scan --mode hosted over a vendored NuGet project doesn't take over (takeover_capable = cargo/npm/golang): redirected: 0, already: 1, and it stays vendored and patched. Not a bug. On an autocrlf checkout, a later revert hits Vendored NuGet on a core.autocrlf checkout: vendor --revert / remove / rollback revert packages.lock.json but leave nuget.config wired, so every restore fails NU1403 (vendor --revert exits 0) #537.
• Fix agent apply writing into shared package stores (#332, #361) #486's shared-store guard (PDM cache, pnpm GVS) doesn't cover ~/.nuget/packages. NuGet agent mode patches the global packages folder by design, so that's not a bug.
• A version bump after vendoring/hosting fails NU1102: the exclusive id-level packageSourceMapping routes the id only to a feed holding the patched version. This is a design limitation; unwind first.
• Hosted remove --offline hint names only nuget.config though packages.lock.json is also rewired. A wording nit, not filed.
• A <packageSourceMapping> key with different case from its <add key>, or a duplicate <packageSources> section: plain dotnet restore fails before socket-patch runs. Invalid fixtures.
• Standalone vex after a hosted scan on a warm, unpatched store says not_applied. That's correct: the installed bytes are pristine (Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 shape).
• A <clear /> placed after an existing <add>: the vendored/hosted catch-all still maps * to the cleared key. NuGet ignores mappings for undefined sources, so it's cosmetic.
• nuget.config spelling priority (nuget.config > NuGet.config > NuGet.Config) matches NuGet in both modes.

[github-actions[bot]]

[agent] 2026-09-30: NuGet / dotnet bug-hunt run

This is the first run, so the ledger started empty and there were no pm:nuget issues to re-triage.

Tested: main f6b7fb9 (#284, <clear /> handling), latest release v4.0.0 (GitHub release binary; v3.3.0 wasn't needed because nothing bisected to a regression). Local SDK: dotnet 8.0.131 (Ubuntu apt; dot.net / builds.dotnet.microsoft.com are blocked by the sandbox proxy, but nuget.org is reachable). Probe SDKs: 6.0.428, 7.0.410, 8.0.425, 9.0.318, 10.0.401.

Setup: there's no Socket API. Agent and vendored cells use a hand-staged .socket/manifest.json plus sha256 git-blob (marker line appended to the real cached Newtonsoft.Json 13.0.3 LICENSE.md), then vendor --offline. The oracle is a real dotnet restore / --locked-mode / dotnet build, checking the extracted LICENSE.md. Hosted cells use scratch tests added locally (not committed) to crates/socket-patch-cli/tests/e2e_nuget_dotnet_build.rs, which reuse its wiremock patch-server stand-in.

Cells

• Vendored, warm global packages folder (same machine), no lock: fail → Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352. Silently unpatched, 0 feed hits, VEX not_affected. Linux 6/7/8/9/10, macOS 8/9, Windows 8/9, and v4.0.0.
• Vendored, warm cache, lock, --locked-mode: fail → Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 (NU1403 right after vendoring), in all 9 probe cells.
• Hosted, warm cache (lock / no lock): fail → Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 (Linux 8, wiremock stand-in).
• Vendored, solution layout (App.sln + root nuget.config, lock in src/App/): fail → Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353. The member lock is untouched, vendor_nuget_no_lockfile falsely says the lock setting is off, and a fresh restore fails NU1403. All 9 probe cells, and v4.0.0.
• Hosted, solution layout: fail → Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 (Linux 8).
• Vendored and hosted, no project nuget.config, source in user-level config (dotnet nuget add source) or a parent-dir config: fail → NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 (NU1101 for packages on the inherited source). Linux 8, main and v4.0.0.
• Vendored, cold cache, root lock: pass (control, all 9 probe cells).
• Vendored, pre-existing NuGet.Config with <clear /> in both sources and mapping: pass (fresh cold --locked-mode installs the patched bytes).
• Vendored, pre-existing mapping that already maps the exact id to nuget.org: pass locally. The folder feed wins 3/3, but see the backlog item on the hosted HTTP race.
• Vendored, Central Package Management (Directory.Packages.props) + lock: pass. Idempotent re-run reports already_vendored; vendor --revert passes.
• Agent apply, then dotnet restore --locked-mode: pass. .nupkg.metadata is deleted and NuGet rewrites it. Patched files are kept.

Issues

• Filed Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352: Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 (warm global packages folder shadows vendored/hosted patches)
• Filed Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353: Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 (member-project packages.lock.json never pinned)
• Filed NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354: NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 (from-scratch * mapping cuts off inherited sources)

False positives ruled out

• The first probe attempt failed in every cell because of my script (bash -e exited on a non-matching grep), not socket-patch. The re-run is clean.
• The blob hash is sha256 git-blob (64 hex). A sha1 git hash-object blob is refused with apply_failed by design.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36755202463 (valid; 9/9 jobs)
• https://github.com/SocketDev/socket-patch/actions/runs/36753875910 and 36755174131 were superseded attempts: a script bug, and a commit that briefly carried a scratch test file, reverted in the next commit.

I couldn't delete probe branch bughunt/nuget/20260930-warmcache-sln: git push --delete got HTTP 403 from the git proxy. A maintainer needs to delete it.

Next

1. Hosted, exact id already mapped to nuget.org in the user's mapping: both HTTP sources serve Newtonsoft.Json 13.0.3, so it may be a nondeterministic race without a lock.
2. NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 on macOS/Windows (%APPDATA%\NuGet\NuGet.Config), plus machine-wide configs.
3. packages.config / packages/ (nuget.exe / msbuild restore, repositoryPath) on the Windows runner, for agent and vendored.
4. globalPackagesFolder / RestorePackagesPath set in nuget.config with projects two levels deep. The agent crawler reads obj/project.assets.json only one level down.
5. Multi-TFM locks, RestoreLockedMode in the csproj, and hosted re-run / rollback refusal (hosted_revert_unsupported) messages.

[github-actions[bot]]

[agent] 2026-09-30 (23:50 UTC): NuGet / dotnet bug-hunt run

Tested: main f6b7fb9 (unchanged since the previous run), release v4.0.0 (GitHub release binary). Local SDK: dotnet 8.0.131 (Ubuntu apt). Probe SDKs: 6.0.428, 9.0.318, 10.0.401 (Linux); 8.0.425 and 9.0.318 (macOS, Windows); nuget.exe 7.9.0.83 (windows-2022, windows-latest).

Re-triage: #352, #353 and #354 were not re-run, because main hasn't moved since they were filed (same SHA, same binary). They stay open.

Cells

• Agent apply, custom globalPackagesFolder (nuget.config) or RestorePackagesPath (Directory.Build.props), warm default ~/.nuget/packages: fail → Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397. The wrong copy (the user-wide cache) is patched, rc 0, and VEX says not_affected. Reproduced on Linux 6/8/9/10, macOS 8/9 and Windows 8/9, for both root-level and src/App projects, on main and on v4.0.0 (not a regression).
• Same, cold default cache, project at src/App: fail → Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397 ("matched no installed package", rc 1, because project.assets.json discovery only goes one level deep). Linux 8.
• Same, cold default cache, project one level deep: pass (control).
• Agent apply, packages.config + repositoryPath=lib/pkgs (nuget.exe restore): fail → Agent-mode NuGet apply ignores nuget.config repositoryPath for packages.config projects and patches ~/.nuget/packages instead, reporting success #398. nuget.exe also fills the global folder, so apply patches that copy even on a cold machine. The lib/pkgs copy stays unpatched, rc 0. windows-2022 and windows-latest.
• Agent apply, packages.config with the default packages/ next to the .sln: pass (Windows ×2).
• Agent rollback / remove / repair --json (isolated NUGET_PACKAGES): pass. Bytes are restored exactly, .nupkg.metadata is recreated by the next --locked-mode restore, and the JSON shapes are sane.
• Vendored, BOM + CRLF NuGet.Config with <clear />: pass. The fresh cold --locked-mode restore gets the patched bytes, and vendor --revert restores the original byte-for-byte (BOM + CRLF kept). Cosmetic only: inserted lines use LF, giving mixed endings until revert.
• Vendored, multi-TFM (net8.0;net6.0;netstandard2.0) + RestoreLockedMode=true in the csproj: pass. All 3 TFM lock sections are re-pinned; cold restore and build succeed.
• Vendored, transitive-only patched package (Newtonsoft.Json 12.0.1 via Newtonsoft.Json.Bson): pass (cold --locked-mode).

Issues

• Filed Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397: Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397
• Filed Agent-mode NuGet apply ignores nuget.config repositoryPath for packages.config projects and patches ~/.nuget/packages instead, reporting success #398: Agent-mode NuGet apply ignores nuget.config repositoryPath for packages.config projects and patches ~/.nuget/packages instead, reporting success #398

False positives ruled out

• Early rollback / remove rollback_failed / missing_blob: my hand-staged manifest had only the after-blob. Once the before-blob was present, both passed.
• rollback with no args emptying the manifest and GC'ing blobs (so a later remove says not_found) is documented in the README command table.
• My first "one-level control" copied a restored tree, so project.assets.json pointed at the original dir. I re-ran it cleanly with per-dir restores.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36791969674 (globalPackagesFolder, 7/7 jobs)
• https://github.com/SocketDev/socket-patch/actions/runs/36792188195 (packages.config repositoryPath, 2/2 jobs)

I couldn't delete the probe branches: git push --delete fails at the git proxy (disconnect/403), the same as last run. A maintainer needs to delete bughunt/nuget/20260930-gpf-first-wins, bughunt/nuget/20260930-pkgconfig-repopath and bughunt/nuget/20260930-warmcache-sln.

Next

1. Hosted, with the exact id already mapped to nuget.org in the user's mapping (possible race with two HTTP sources).
2. NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 on macOS/Windows (%APPDATA%\NuGet\NuGet.Config) and machine-wide configs.
3. Vendored/hosted with packages.config (packages/, repositoryPath): does vendoring handle a project with no PackageReference / no lock?
4. The scan crawler with globalPackagesFolder: does scan also miss or misreport packages (Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397's sibling in the read path)?
5. Unicode / space-containing paths and Windows long paths for agent apply and vendor.

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major NuGet / dotnet version and on Linux, macOS and Windows.

Where NuGet / dotnet puts global installs: The global packages folder (~/.nuget/packages, NUGET_PACKAGES, globalPackagesFolder) and dotnet tool install -g (~/.dotnet/tools/.store). See #352 and #397.

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed NuGet / dotnet package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a NuGet / dotnet project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × NuGet / dotnet version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

[agent] 2026-10-01 (05:47 UTC): NuGet / dotnet bug-hunt run

Tested: main 2463257 (#277, the v5 consolidation; the binary still reports 4.0.0), plus the latest release v4.0.0 (GitHub release binary) for regression checks. Local SDK: dotnet 8.0.131 (Ubuntu apt). Probe SDKs: Linux 6.0.x / 9.0.x / 10.0.x, macOS 8.0.x / 9.0.x, Windows 8.0.x / 9.0.x / 10.0.x.

This run focused on the maintainer's global-mode (-g) request (20261001T040000Z entry).

Setup: global installs are real ones: dotnet restore fills ~/.nuget/packages, and dotnet tool install -g dotnetsay fills ~/.dotnet/tools/.store. A local Python stand-in for the public proxy answers POST /patch/batch (a patch for every nuget purl, with the request body logged as the oracle for "what did scan find") and, for agent cells, also GET /patch/by-package and /patch/view. Apply / rollback / vex cells use a hand-staged .socket/manifest.json plus sha256 git-blob hashes.

Re-triage

• Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397: still reproduces on 2463257 (src/App + project globalPackagesFolder: wrong copy patched, VEX not_affected). I commented with this and the new -g evidence: Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397 (comment)
• Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352, Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353, NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354, Agent-mode NuGet apply ignores nuget.config repositoryPath for packages.config projects and patches ~/.nuget/packages instead, reporting success #398 were not re-run this time (the v5 vendor flow needs server artifacts; Agent-mode NuGet apply ignores nuget.config repositoryPath for packages.config projects and patches ~/.nuget/packages instead, reporting success #398 is Windows / nuget.exe only). They stay open.

Cells (global mode)

• scan -g report-only, default folder: pass. It finds every ~/.nuget/packages package, with correct versions, and --json is sane. Linux 8, plus all 8 probe cells.
• scan -g vs dotnet tool install -g: fail → Global scan (-g) never crawls .NET global tools (~/.dotnet/tools/.store), so a patched dotnet tool install -g package is silently left out of scan, apply and vex on every OS #426. The tool store is never crawled. --global-prefix ~/.dotnet/tools/.store finds 0 packages; only the per-tool .store/<id>/<ver> works. apply -g fails loudly (rc 1, not found), and vex -g gives package_not_found. Reproduced in all 9 cells (local + 8 probe), and on v4.0.0.
• scan -g / apply -g / vex -g with a user-level globalPackagesFolder: fail → Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397 (comment). Scan misses the real folder, apply patches ~/.nuget/packages, and VEX says not_affected. Reproduced in all 9 cells.
• scan -g --mode hosted and scan --global-prefix <dir> --mode hosted: pass. Both refuse with exit 2 and write nothing.
• apply -g → real dotnet build → vex -g → rollback -g, default folder: pass. The patched bytes are used by the build, VEX attests only while applied (0 statements after rollback), and rollback is byte-exact.
• SOCKET_GLOBAL=1, SOCKET_GLOBAL_PREFIX, and --global-prefix with spaces + unicode: pass (same discovery as -g).
• scan -g from inside a packages.config project: pass. The project's packages/ doesn't leak into -g.
• Project-mode scan (no -g): fail → Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427. It lists the whole ~/.nuget/packages, and scan --mode agent patches an unrelated cached package (serilog) and VEX attests it as a subcomponent of the product. Linux 8, 2/2 runs, and the same on v4.0.0.
• Unwritable global dir (root-owned prefix / Program Files): blocked. The sandbox runs as root; this needs a probe with chmod as the runner user.

Issues

• Filed Global scan (-g) never crawls .NET global tools (~/.dotnet/tools/.store), so a patched dotnet tool install -g package is silently left out of scan, apply and vex on every OS #426: Global scan (-g) never crawls .NET global tools (~/.dotnet/tools/.store), so a patched dotnet tool install -g package is silently left out of scan, apply and vex on every OS #426 (-g never crawls ~/.dotnet/tools/.store)
• Filed Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427: Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427 (project scan crawls the whole global packages folder; false VEX subcomponent)
• Commented on Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397 (re-triage, plus the user-level globalPackagesFolder breaking -g)

False positives ruled out

• dotnet nuget config set globalPackagesFolder didn't write anything on SDK 8.0.131. I edited NuGet.Config by hand and confirmed with dotnet nuget locals global-packages -l before testing.
• The early "nothing applied" after rollback with no targets was the documented manifest wipe. I re-staged between runs.

Observed, not filed (cross-PM, not NuGet-specific)

• scan -g --mode vendored isn't refused up front (it reached "could not fetch patch details" against the stand-in), and get -g --mode hosted runs a hosted lookup instead of refusing like scan -g --mode hosted. Neither is NuGet-specific and I didn't prove either does damage. Left for the general routine or a maintainer.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36820498426 (8/8 jobs, all cells reproduce Global scan (-g) never crawls .NET global tools (~/.dotnet/tools/.store), so a patched dotnet tool install -g package is silently left out of scan, apply and vex on every OS #426 and the Agent-mode NuGet apply patches ~/.nuget/packages instead of the project's configured globalPackagesFolder / RestorePackagesPath, reports success, and VEX attests not_affected #397 -g variant)

git push --delete hung up at the git proxy again, so a maintainer needs to delete bughunt/nuget/20261001-global-mode (plus the three 20260930 branches listed in the previous entries).

Next

1. Global mode: an unwritable global packages folder (chmod as a non-root runner user; on Windows, a folder under Program Files) must fail loudly.
2. Global mode: dotnet tool install --tool-path <dir> and local tools (.config/dotnet-tools.json restore into ~/.nuget/packages).
3. Re-run Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 / Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 / NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 under the v5 vendored flow (the server-artifact path may need the e2e wiremock harness).
4. Hosted: exact id already mapped to nuget.org in the user's mapping (possible race between two HTTP sources).
5. Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427 on macOS / Windows, and whether hosted mode with a lock is affected.

[github-actions[bot]]

[agent] 2026-10-01 (12:20 UTC): NuGet / dotnet bug-hunt run

Tested: main 2463257 (unchanged since the last run; the binary reports 4.0.0), release v4.0.0. Local SDK: dotnet 8.0.131 (Ubuntu apt). dot.net's dotnet-install.sh is blocked by the proxy (403), so SDK 6/9/10 weren't available locally. No probe branch this run.

Setup: a non-root user (hunter) for the permission cells, with hand-staged .socket/manifest.json + sha256 git-blob hashes. For the v5 vendored and hosted cells, a scratch copy of e2e_nuget_dotnet_build.rs (the wiremock Backend stand-in plus a real nuget.org fixture restore), deleted after the run.

Re-triage

• Main is unchanged, so nothing could have been fixed. Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 was re-run under the v5 flow and still reproduces (hosted + vendored, warm cache → NU1403 on both locked and plain restore, with no scan warning). Comment: Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 (comment)

Cells

• Unwritable global packages folder (non-root, root-owned chmod a-w), project mode NUGET_PACKAGES and apply -g ~/.nuget/packages: pass. rc 1, apply_failed "Permission denied (os error 13)", nothing written, and VEX omits it (not_applied). The error names no path, which is cosmetic.
• Partially writable package (one subdir read-only, 3-file patch): pass by design. Two files are patched, rc 1 partialFailure, VEX omits it, and rollback restores both files (rolledBack 1). apply.rs documents partial-apply + retry as intended behaviour.
• dotnet tool install --tool-path: fail → Global scan (-g) never crawls .NET global tools (~/.dotnet/tools/.store), so a patched dotnet tool install -g package is silently left out of scan, apply and vex on every OS #426 (comment). apply --global-prefix <tt>/.store, <tt> and -g all give package_not_installed. Global scan (-g) never crawls .NET global tools (~/.dotnet/tools/.store), so a patched dotnet tool install -g package is silently left out of scan, apply and vex on every OS #426 (comment)
• v5 vendored / hosted, warm cache: fail → Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 (see above).
• Hosted, user nuget.config already maps the exact id to nuget.org: fail → Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462. The rewriter adds a second exact-id mapping, which ties with the user's. If the Socket feed is slower (stand-in index.json delayed 3 s), the locked restore fails NU1403 and the lockless restore exits 0 with unpatched bytes. Reproduced 2/2. The control (default config, same delay) passes, and at 0 ms / 500 ms the local stand-in wins.
• Vendored with the same user mapping: the config has the same tie, but restore passed (the local folder feed wins). It's listed in Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462.

Issues

• Filed Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462: Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462
• Commented on Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 and Global scan (-g) never crawls .NET global tools (~/.dotnet/tools/.store), so a patched dotnet tool install -g package is silently left out of scan, apply and vex on every OS #426.

False positives ruled out

• Partial apply leaving files patched after a mid-flight EACCES is intended (apply.rs: "a previous apply that failed partway left them patched"). It's loud (rc 1), VEX doesn't attest it, and rollback restores it.
• The first rollback envelope "missing summary" was my parser: rollback's envelope has a different shape (rolledBack, results), not summary.

Next

1. Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462 on macOS / Windows and SDK 6/9/10 (probe branch; the bh harness must be inlined into the workflow, or use a Python stand-in).
2. Re-run Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 / NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 under the v5 flow (the harness approach from this run works).
3. Local tools (.config/dotnet-tools.json) in project vs -g mode, plus Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427 on macOS / Windows.
4. A prefix pattern (Newtonsoft.*) on another source, which the exact id should beat (expect pass), and a case-variant exact id (newtonsoft.json).
5. Unicode / space paths and Windows long paths (agent + vendor).

Probe branches still waiting for a maintainer to delete: bughunt/nuget/20261001-global-mode and the three 20260930 branches (see the earlier entries).

[github-actions[bot]]

[agent] 2026-10-01 (17:50 UTC): NuGet / dotnet bug-hunt run

Tested: main 9d718cf (19 commits since 2463257, including #446 "-g touching the cwd project's state"), release v4.0.0. Local SDK: dotnet 8.0.131 (Ubuntu apt). For the bisect I also built c7af4df, the parent of #446. No probe branch this run.

Setup: a scratch copy of e2e_nuget_dotnet_build.rs, with the wiremock Backend and a real nuget.org fixture restore, plus a step runner (scan -g, rollback -g, a staged before-blob, a locked restore, vex). I deleted it after the run. A Python stand-in proxy served the report-only scans.

Re-triage

• Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427: still reproduces on 9d718cf. A report-only scan --json in a Newtonsoft-only project sends serilog@3.1.1 (left over from another project) in the batch, and nuget_crawler.rs is unchanged. No comment; nothing new.
• No other pm:nuget issue was touched by main. None of the 19 new commits change NuGet code.

Cells

• Fix -g touching the cwd project's state (#436, #445) #446 × vendored NuGet: scan -g --mode agent → rollback -g, run from the vendored project: fail → Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489. The global packages folder copy is the project's install. scan -g reports applied: 1 on bytes that are already patched and writes an agent manifest record. rollback -g restores upstream bytes, the --locked-mode restore says "up-to-date", and VEX still attests (vendored). 3/3 on main. On c7af4df the agent leg is skipped (vendored_ownership_retained), so this is a regression from 551c362. Before that, rollback -g hit rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 and failed loudly (NU1403).
• The same cell in hosted mode: fail → Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 (comment). Silently unpatched on main and on c7af4df, so it predates Fix -g touching the cwd project's state (#436, #445) #446.
• rollback -g alone from a vendored project (v5, no manifest): pass. It fails with "Manifest not found" and the store stays patched.
• scan -g discovery with NUGET_PACKAGES set: pass. It reads only that folder; 4 unique purls, no duplicates.

Issues

• Filed Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489: Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489
• Commented on Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 (hosted variant): Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 (comment)

False positives ruled out

• The scan -g --json packages[] listed Newtonsoft.Json@13.0.3 twice in the harness. The batch request carried it once, so the doubling came from the stand-in's response, not a crawler duplicate.
• The vex -o flag is --org, not output (-O/--output). My first vex runs printed the document to stdout. The attestation result still holds.

Next

1. Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 on macOS / Windows and SDK 6/9/10 (probe branch; the harness must be inlined into the workflow).
2. apply -g / remove -g <purl> from a vendored NuGet project (the same class as Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489).
3. Re-run Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 / NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 under the v5 flow.
4. Local tools (.config/dotnet-tools.json), and Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427 on macOS / Windows.
5. Mapping edge cases: a case-variant exact id (newtonsoft.json), and a prefix pattern on another source.

[github-actions[bot]]

[agent] 2026-10-01 (23:45 UTC): NuGet / dotnet bug-hunt run

Tested: main 61cfb9b (one commit since 9d718cf: #365, an npm crawler fix, with no NuGet code touched), release v4.0.0. Local SDK: dotnet 8.0.131 (Ubuntu apt). No probe branch this run.

Setup: a scratch copy of e2e_nuget_dotnet_build.rs (the wiremock Backend stand-in plus a real nuget.org fixture restore), with a lock-name and config parameter. I deleted it after the run.

Re-triage

• Main's only new commit is npm-only, so no open pm:nuget issue can have changed. No re-runs, no comments.
• Nobody has replied on the discussion.

Cells (Linux, SDK 8.0.131)

• Per-project lock packages.app.lock.json (NuGet's packages.<ProjectName>.lock.json convention; NuGet uses it instead of packages.lock.json): fail → Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514, both vendored and hosted, reproduced 2/2. The named lock isn't re-pinned, and both locked and plain fresh restores fail NU1403. Scan exits 0, and the in-run VEX attests. Vendored also wrongly says "no packages.lock.json (RestorePackagesWithLockFile is off)". The control with the default lock name passes.
• Self-closing <packageSourceMapping /> in an existing config: pass (vendored + hosted). A second <packageSourceMapping> section is appended, NuGet merges the two, and locked and plain restores install the patched bytes.
• Prefix pattern Newtonsoft.* + * on nuget.org, with the Socket exact id added: pass (vendored + hosted). The exact id wins.

Issues

• Filed Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514: Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514

False positives ruled out

• The duplicate <packageSourceMapping> element from a self-closing original is cosmetic. NuGet merges same-name sections, and the restore is correct.

Next

1. Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514 on macOS / Windows and SDK 6/9/10, plus the custom NuGetLockFilePath property variant (probe branch).
2. Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 on macOS / Windows and SDK 6/9/10 (probe branch; inline the harness).
3. apply -g / remove -g <purl> from a vendored NuGet project (the Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 class).
4. Re-run Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 / NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 under the v5 flow.
5. Local tools (.config/dotnet-tools.json); packages.config vendored/hosted (Windows runner).

[github-actions[bot]]

[agent] 2026-10-02 (05:58 UTC): NuGet / dotnet bug-hunt run

Tested: main 61cfb9b (no new commits since the last run), release v4.0.0. Local SDK: dotnet 8.0.131 (Ubuntu apt). One probe branch: bughunt/nuget/20261002-crlf-revert, a 6-cell matrix of {ubuntu, macos, windows}-latest × SDK {8, 10}. Run: https://github.com/SocketDev/socket-patch/actions/runs/36970426074

Setup: a scratch copy of e2e_nuget_dotnet_build.rs with the wiremock Backend stand-in and a real nuget.org fixture restore. A new scratch_serve test starts the backend and then either waits, so the shell can drive it, or runs a bash probe script (SCRATCH_SCRIPT). The probe workflow inlines both files with heredocs. Everything was deleted locally after the run.

Re-triage

• Main is unchanged and no pm:nuget issue was touched, so nothing needed re-running. A maintainer triaged Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514 and Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 together (shared lock-discovery root cause). Nobody has replied on the discussion.

Cells

• Vendored + core.autocrlf=true checkout → vendor --revert / remove / rollback / rescan→revert: fail → Vendored NuGet on a core.autocrlf checkout: vendor --revert / remove / rollback revert packages.lock.json but leave nuget.config wired, so every restore fails NU1403 (vendor --revert exits 0) #537. The lock is reverted but nuget.config is drift-kept (its LF-anchored fragments don't match CRLF), so every restore fails NU1403. vendor --revert exits 0 with "success". Reproduced 3× in the sandbox (once with sed CRLF, twice with a real git clone -c core.autocrlf=true) and on ubuntu 8/10, macOS 8 and Windows 8/10. On the Windows runner, Git's system autocrlf default is in effect. For macOS 10, only the named-lock part of the log was inspected.
• Control: the same commit cloned without autocrlf passes (byte-exact revert).
• Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514 named lock packages.app.lock.json (vendored): fail on all 6 probe cells (macOS / Windows / SDK 10 are new) → commented on Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514.
• Custom NuGetLockFilePath=locks/app.lock.json (vendored): fail on all 6 cells plus the sandbox: vendor_nuget_no_lockfile, the lock isn't re-pinned, NU1403 → included in the Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514 comment.
• Vendored, then dotnet nuget add source (NuGet re-serializes nuget.config, adds a BOM), then vendor --revert: pass. Excision removed our source and mapping, the lock went back to the nuget.org contentHash, and the locked restore installed the pristine package.
• Vendored with a CRLF original config, later normalized to LF, then revert: pass (excision path; see Known non-bugs).

Issues

• Filed Vendored NuGet on a core.autocrlf checkout: vendor --revert / remove / rollback revert packages.lock.json but leave nuget.config wired, so every restore fails NU1403 (vendor --revert exits 0) #537: Vendored NuGet on a core.autocrlf checkout: vendor --revert / remove / rollback revert packages.lock.json but leave nuget.config wired, so every restore fails NU1403 (vendor --revert exits 0) #537
• Commented on Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514: Vendored and hosted NuGet ignore a per-project packages.<project>.lock.json, so the lock is never re-pinned and every later restore fails NU1403 while VEX attests the patch #514 (comment)

False positives ruled out

• The <packageSourceMapping> *→nuget.org catch-all stays behind after a drift-path (excision) revert. The code does that on purpose (the revert_config_record doc), and it's harmless: it routes to the only pre-existing source.
• vendor -g / vendor --revert -g rewiring the cwd project is generic, not NuGet-specific. It's vendor -g and vendor --revert -g still rewire the current project: on vlt, --revert -g silently unpatches a vendored project (the #446 fix skipped vendor.rs) #498 (vlt routine), with PR Fix vendor -g rewiring the cwd project (#498) #499 open. Not re-filed.

Blocked

• Probe-branch deletion is blocked by the sandbox proxy. git push --delete fails with "remote end hung up", and the REST DELETE git/refs returns 403 "Write access to this GitHub API path is not permitted". These remote branches are still there and need a maintainer to delete them: bughunt/nuget/20261002-crlf-revert, bughunt/nuget/20260930-gpf-first-wins, bughunt/nuget/20260930-pkgconfig-repopath, bughunt/nuget/20260930-warmcache-sln, bughunt/nuget/20261001-global-mode.

Next

1. The autocrlf class in hosted mode: a hosted→vendored takeover and a vendored→hosted takeover on a CRLF checkout (the takeover reverts vendored wiring first).
2. Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 on macOS / Windows (the probe harness pattern from this run works; reuse it).
3. Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462 / Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 / NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 on macOS / Windows and SDK 6/9 via the same probe harness.
4. Local tools (.config/dotnet-tools.json), and apply -g / remove -g from a vendored project.
5. packages.config vendored/hosted on a windows-latest probe (nuget.exe).

[github-actions[bot]]

[agent] 2026-10-02 (11:44 UTC): NuGet / dotnet bug-hunt run

Tested: main 61cfb9b (no new commits since the last run), release v4.0.0. Local SDK: dotnet 8.0.131 (Ubuntu apt). No probe branch this run.

Setup: a scratch copy of e2e_nuget_dotnet_build.rs with the wiremock Backend and a real nuget.org fixture restore, plus the scratch_serve test that runs a SCRATCH_SCRIPT bash probe. Deleted locally after the run.

Re-triage

• Main is unchanged and no pm:nuget issue moved, so nothing needed re-running. Nobody has replied on the discussion.

Cells (Linux, SDK 8.0.131)

• Hosted → vendored (scan --mode vendored over a hosted project): fail → NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553. Reproduced 4×: autocrlf false and true, the http stand-in URL, and the production https://patch.socket.dev/… URL (sed). There's no takeover (hosted_pin_of compares pkg:nuget/newtonsoft.json from discovery against pkg:nuget/Newtonsoft.Json case-sensitively). The vendored backend reads hosted's socket-patch-<uuid> key as its own wiring and takes the "artifact rebuilt (nuget.config untouched)" branch. The run exits 0 success, the hosted feed stays wired, there's no state.json, list still says hosted, and the next vendor --revert deletes the nupkg as an orphan. --dry-run shows no vendor_would_revert_redirect.
• Control: vendor over the same hosted project: pass. It uses the discovered lowercase purl: takeover, ledger written, local feed wired, list says vendored, and the locked restore installs patched bytes.
• remove / rollback pkg:nuget/Newtonsoft.Json@13.0.3 (the spelling scan prints) on a hosted project: fail → NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553 (not_found, exit 1). The lowercase purl works (hosted_reverted, plus the nuget_default_config_left advisory).
• Vendored → hosted (scan --mode hosted over a vendored project): no takeover for NuGet. takeover_capable is cargo/npm/golang only. It reports redirected: 0, rollout already: 1, the project stays vendored, and restore installs patched bytes. Recorded as by-design (see Known non-bugs). With autocrlf, the follow-up remove fails with drift-kept NU1403, which is just Vendored NuGet on a core.autocrlf checkout: vendor --revert / remove / rollback revert packages.lock.json but leave nuget.config wired, so every restore fails NU1403 (vendor --revert exits 0) #537.
• Hosted → vendored → vendor --revert, autocrlf false and true: given NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553, this "reverts" only the orphan nupkg, and the project stays hosted (patched). That's covered by NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553.

Issues

• Filed NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553: NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553

False positives ruled out

• Vendored → hosted leaving NuGet vendored: by design (no NuGet vendored→hosted takeover; the patch stays applied).
• The nuget.config key list showing each socket-patch-<uuid> key twice: that's the packageSources + packageSourceMapping pair, not a duplicate source.

Blocked

• Probe-branch deletion is still blocked (see 2026-10-02 05:58). I pushed no new branch this run.

Next

1. get --mode vendored over a hosted project (expect NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553 too; confirm).
2. NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553's case-sensitivity elsewhere: vex/list with a mixed-case --package, and vendor --revert <Mixed.Case purl>.
3. Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 on macOS / Windows and SDK 6/9/10 (probe harness).
4. Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462 / Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 / NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 on macOS / Windows and SDK 6/9.
5. Local tools (.config/dotnet-tools.json); packages.config vendored/hosted on windows-latest.

[github-actions[bot]]

[agent] 2026-10-02 (17:42 UTC): NuGet / dotnet bug-hunt run

Tested: main 6cd3754 (22 new commits since 61cfb9b, none of which touch NuGet code: crawler, vendor nuget_feed, redirect NuGet and formats::nuget are all unchanged), release v4.0.0 (npm). Local SDK: dotnet 8.0.131 (Ubuntu apt). The SDK 10 install via dotnet-install.sh is blocked by the sandbox proxy (builds.dotnet.microsoft.com 403). No probe branch this run, because the new defect is OS-independent text splicing and probe-branch deletion is still blocked.

Setup: a scratch copy of e2e_nuget_dotnet_build.rs plus a scratch_serve test that runs a SCRATCH_SCRIPT bash probe against the wiremock Backend. Note: --vendor-source build was removed; the vendored leg now needs --vendor-source service --patch-server-url <backend>. Deleted locally after the run.

Re-triage

• Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 (scan -g --mode agent → rollback -g from a vendored project): still fails on 6cd3754. The store is PRISTINE after rollback -g, and the locked restore is "up-to-date" and stays PRISTINE. No comment (no new information).
• Fix agent apply writing into shared package stores (#332, #361) #486 (shared-store guard for agent apply) only classifies PDM's cache and pnpm's GVS. NuGet's global packages folder is outside its scope, and patching it there is documented NuGet agent behaviour, so I filed nothing.
• New pm:nuget issue Hosted NuGet mapping reads commented-out package sources #561 (arch-audit, hosted reads commented-out source keys) is noted here. Not mine; untouched.

Cells (Linux, SDK 8.0.131)

• Hosted, commented-out <packageSources> before the real one: fail → Hosted NuGet splices the Socket source (and mapping) into a commented-out &lt;packageSources&gt; / &lt;packageSourceMapping&gt; block, so every restore fails NU1100 while scan reports success and its in-run VEX attests not_affected #585. The Socket <add> (and the seeded nuget.org) is spliced inside the comment. Scan exits 0 success, the in-run VEX says not_affected, and every restore fails NU1100. A re-run reports redirected: 1 and changes nothing. Standalone vex flags patched_ref_invalid and errors. remove <purl> gives manifest_not_found. Reproduced 3× on main, and also on v4.0.0 (not a regression).
• Hosted, commented-out <packageSourceMapping>: fail → Hosted NuGet splices the Socket source (and mapping) into a commented-out &lt;packageSources&gt; / &lt;packageSourceMapping&gt; block, so every restore fails NU1100 while scan reports success and its in-run VEX attests not_affected #585. The whole mapping is spliced into the comment, so no live mapping exists. The cold locked restore happened to install patched bytes.
• Vendored, both commented variants: pass (it blanks comments).
• Control (no comments), hosted and vendored: pass.
• get <uuid|purl> --mode vendored over a hosted project: fail, as NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553 predicted. I commented on NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553 (vendor_artifact_rebuilt "nuget.config untouched", no state.json, hosted feed still wired).

Issues

• Filed Hosted NuGet splices the Socket source (and mapping) into a commented-out &lt;packageSources&gt; / &lt;packageSourceMapping&gt; block, so every restore fails NU1100 while scan reports success and its in-run VEX attests not_affected #585: Hosted NuGet splices the Socket source (and mapping) into a commented-out &lt;packageSources&gt; / &lt;packageSourceMapping&gt; block, so every restore fails NU1100 while scan reports success and its in-run VEX attests not_affected #585
• Commented on NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553: NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553 (comment)

False positives ruled out

• Fix agent apply writing into shared package stores (#332, #361) #486's shared-store guard skipping ~/.nuget/packages: NuGet agent mode patches the global packages folder by design (docs/ecosystems.md NuGet row). Not a bug.
• The Hosted NuGet splices the Socket source (and mapping) into a commented-out &lt;packageSources&gt; / &lt;packageSourceMapping&gt; block, so every restore fails NU1100 while scan reports success and its in-run VEX attests not_affected #585 variant A failure isn't Hosted NuGet mapping reads commented-out package sources #561: the commented block has no <add>, so the key reader isn't involved. Hosted NuGet mapping reads commented-out package sources #561 itself asked for the splice-anchor case to be filed separately.

Blocked

• SDK 6/9/10 can't be installed in the sandbox (dotnet-install 403). Probe-branch deletion is still blocked (5 old bughunt/nuget/* branches remain).

Next

1. NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553 case sensitivity in vex --package, vendor --revert <Mixed.Case purl>, list.
2. Hosted NuGet splices the Socket source (and mapping) into a commented-out &lt;packageSources&gt; / &lt;packageSourceMapping&gt; block, so every restore fails NU1100 while scan reports success and its in-run VEX attests not_affected #585 on a real <packageSourceMapping> placed after a commented one (expect NU1403 with a lock), and hosted revert after a hand-fixed config.
3. Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 / Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462 / Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 / NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 on macOS / Windows and SDK 6/9/10 via a probe branch (once deletion works, or batched into one branch).
4. Local tools (.config/dotnet-tools.json); packages.config vendored/hosted on windows-latest.

[github-actions[bot]]

[agent] 2026-10-02 (23:50 UTC): NuGet / dotnet bug-hunt run

Tested: main 045d7ec (13 new commits since 6cd3754; none change NuGet rewriting. redirect/mod.rs diffs are other ecosystems plus moved NuGet tests), release v4.0.0 (npm; main still reports 4.0.0). Local SDK: dotnet 8.0.131 (Ubuntu apt; the container no longer ships it, so this run reinstalled it). No probe branch: both new defects are platform-independent, and probe-branch deletion is still blocked.

Setup: a scratch copy of e2e_nuget_dotnet_build.rs plus a scratch_serve test that runs a SCRATCH_SCRIPT bash probe against the wiremock Backend (env: URI, UUID, SP, FIXTURE, STORE_FX, SBROOT). Deleted locally after the run.

Re-triage

• No NuGet code changed on main, so every open pm:nuget issue stands. Hosted NuGet splices the Socket source (and mapping) into a commented-out &lt;packageSources&gt; / &lt;packageSourceMapping&gt; block, so every restore fails NU1100 while scan reports success and its in-run VEX attests not_affected #585's splice (insert_nuget_source open-tag match on unmasked text) is unchanged on 045d7ec.
• New arch-audit issues Hosted NuGet rewrites packages.lock.json entries at other versions of the patched id #593 / Read and splice nuget.config through formats::nuget in hosted, vendored and restore #594 and the Tracking: scope project-mode cache crawls to what the project resolves #595 tracking link on Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427 are noted. Not mine; untouched.

Cells (Linux, SDK 8.0.131)

• CPM + CentralPackageTransitivePinningEnabled (patched id only transitive via Newtonsoft.Json.Bson, lock type CentralTransitive): hosted pass, vendored pass (lock re-pinned, fresh-checkout locked restore installs PATCHED).
• BOM packages.lock.json (dotnet restores it fine): hosted fail → Hosted and vendored NuGet reject a packages.lock.json with a UTF-8 BOM that dotnet restores fine: hosted skips the redirect and exits 0 success, vendored fails apply_failed #623 (redirect_nuget_lock_unparseable, exit 0 success, nothing wired); vendored fail → Hosted and vendored NuGet reject a packages.lock.json with a UTF-8 BOM that dotnet restores fine: hosted skips the redirect and exits 0 success, vendored fails apply_failed #623 (apply_failed, exit 1). Reproduced 3× on main. v4.0.0: hosted wires the config but leaves the lock, so NU1403; vendored is the same. Not a regression.
• Hosted BOM + CRLF nuget.config: scan + locked restore pass. Hosted remove with LF / CRLF / BOM config: config byte-exact pass.
• Hosted unwind lock hash: fail → Hosted NuGet remove / rollback / takeover restore packages.lock.json to the nuget.org catalog packageHash, which isn't NuGet's contentHash for signed packages, so every later dotnet restore fails NU1403 #624. remove, rollback <purl> and hosted → vendor takeover → vendor --revert all write the nuget.org catalog packageHash (sha512 of the signed nupkg file, mbJSv…) instead of NuGet's signature-excluded contentHash (HrC5…), so every later restore (locked or plain) fails NU1403. Reproduced 5×. Introduced by de316b4 (Keep Composer redirects and rollback consistent #358); v4.0.0 has no manifest-less hosted unwind.
• Vendored remove / rollback purl case: mixed-case pkg:nuget/Newtonsoft.Json@13.0.3 works; lowercase gives not_found, exit 1 (the inverse of hosted). Commented on NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553.

Issues

• Filed Hosted and vendored NuGet reject a packages.lock.json with a UTF-8 BOM that dotnet restores fine: hosted skips the redirect and exits 0 success, vendored fails apply_failed #623: Hosted and vendored NuGet reject a packages.lock.json with a UTF-8 BOM that dotnet restores fine: hosted skips the redirect and exits 0 success, vendored fails apply_failed #623
• Filed Hosted NuGet remove / rollback / takeover restore packages.lock.json to the nuget.org catalog packageHash, which isn't NuGet's contentHash for signed packages, so every later dotnet restore fails NU1403 #624: Hosted NuGet remove / rollback / takeover restore packages.lock.json to the nuget.org catalog packageHash, which isn't NuGet's contentHash for signed packages, so every later dotnet restore fails NU1403 #624
• Commented on NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553: NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553 (comment)

False positives ruled out

• Hosted remove / rollback giving manifest_not_found on a manifest-less hosted project was a harness artifact: lockfile discovery only recognises production https://patch.socket.dev feed URLs, and the stand-in writes http://127.0.0.1. After a sed to the production URL it gives hosted_reverted. Always rewrite the URL before unwind probes.
• Version bump after vendoring/hosting (the exclusive id mapping routes only to a feed holding the patched version, so NU1102): a design limitation of id-level packageSourceMapping, not filed.

Next

1. Hosted NuGet remove / rollback / takeover restore packages.lock.json to the nuget.org catalog packageHash, which isn't NuGet's contentHash for signed packages, so every later dotnet restore fails NU1403 #624 follow-ups: an unsigned (non-nuget.org-signed) package hash path; the --offline refusal wording.
2. Hosted and vendored NuGet reject a packages.lock.json with a UTF-8 BOM that dotnet restores fine: hosted skips the redirect and exits 0 success, vendored fails apply_failed #623 on Windows with a PowerShell-written lock (probe branch, if deletion works).
3. Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 / Hosted/vendored NuGet mapping isn't exclusive when nuget.config already maps the exact package id to another source, so restore races the Socket feed against nuget.org (NU1403 with a lock, silently unpatched without one) #462 / Vendored and hosted NuGet leave member-project packages.lock.json unpinned in a solution layout, so every fresh restore fails NU1403 #353 / NuGet nuget.config authored by vendored/hosted mode maps '*' only to nuget.org, cutting off sources inherited from parent or user-level configs (NU1101) #354 on macOS / Windows and SDK 6/9/10.
4. Local tools (.config/dotnet-tools.json); packages.config vendored/hosted on windows-latest.
5. Mapping edge cases: a case-variant exact id in a user mapping, and two Socket patches for different ids.

[github-actions[bot]]

[agent] 2026-10-03 (UTC): NuGet / dotnet bug-hunt run

Tested: main 045d7ec (unchanged since the last run), release v4.0.0 (npm, used to bisect). Local SDK: dotnet 8.0.131 (Ubuntu apt, reinstalled). No probe branch: deleting branches is still blocked from the sandbox (git push --delete was denied again), so I won't push new probe branches until a maintainer clears the 5 stale bughunt/nuget/* branches.

Setup: the scratch_serve harness, a scratch copy of e2e_nuget_dotnet_build.rs that runs a bash SCRATCH_SCRIPT against the wiremock Backend. Deleted after the run.

Re-triage

• main hasn't moved and no NuGet fix PR is open (only Read NuGet and Cargo crawler project files through the FIFO-safe reader (#592) #602, which is FIFO-safe reads), so every open pm:nuget issue stands. Maintainer triage on Hosted and vendored NuGet reject a packages.lock.json with a UTF-8 BOM that dotnet restores fine: hosted skips the redirect and exits 0 success, vendored fails apply_failed #623 / Hosted NuGet remove / rollback / takeover restore packages.lock.json to the nuget.org catalog packageHash, which isn't NuGet's contentHash for signed packages, so every later dotnet restore fails NU1403 #624 (p3) noted.

Cells (Linux, SDK 8.0.131; hosted + vendored unless noted)

• RID lock sections (RuntimeIdentifiers linux-x64;win-x64): pass. The id is only in the net8.0 section; re-pinned; a fresh locked restore installs PATCHED.
• Custom source key + <clear /> (only Corp → nuget.org v3, no mapping): pass. The catch-all maps * to Corp.
• Existing Newtonsoft.* + * mapping under nuget.org: pass. The exact-id Socket pattern wins.
• Lowercase PackageReference Include="newtonsoft.json": pass. The lock stores the canonical Newtonsoft.Json, so this cell is moot. Hosted and vendored re-runs are byte-idempotent.
• --dry-run: pass. Nothing written in either mode.
• Symlinked nuget.config / packages.lock.json: hosted pass (refuses with redirect_symlinked_file_unsupported, also under --dry-run). Vendored fail: exit 0, the link becomes a regular file, --dry-run predicts nothing, and vendor --revert restores the bytes but not the link. Reproduced 2×. v4.0.0 is the same. Same root cause as Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 (vendored group commit has no symlink gate), so I commented there rather than filing.
• Space / unicode / & in the project path (a & b ü, checked out to co x & é): pass.
• CPM VersionOverride (central 13.0.1, override 13.0.3): pass.
• Hosted remove / rollback --offline: pass. Loud refusal (hosted_revert_failed / partial_failure, exit 1) and nothing written. Nit (not filed): the hint says git checkout -- nuget.config, but packages.lock.json is also rewired and needs the same checkout.
• Concurrent scans (two at once): pass. One succeeds and the other gets lock_held; one source, one mapping, one pin.
• list on a hosted project: reports pkg:nuget/newtonsoft.json@13.0.3 (lowercase); vendored reports mixed case. Same split as NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553, no new issue.
• Standalone vex on a warm, unpatched store after hosted scan: not_applied, exit 1. That's correct (the installed bytes are pristine; it's the Vendored and hosted NuGet patches are shadowed by a warm global packages folder: silently unpatched without a lock, NU1403 with one #352 shape), not a bug.

Issues

• Commented on Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 (NuGet vendored has the same symlink gap): Vendored yarn classic replaces a symlinked yarn.lock with a regular file (hosted refuses the same lock), leaving the link's target unpatched; rollback never restores the link #627 (comment)
• No new issues filed.

False positives ruled out

• A <packageSourceMapping> key whose case differs from the <add key>, and two <packageSources> sections with a disabled nuget.org: plain dotnet restore already fails NU1100 before socket-patch runs. Invalid fixtures.

Next

1. Remaining SDK 6/9/10 + macOS/Windows cells, once probe branches can be deleted (or a maintainer OKs leaving them).
2. Hosted NuGet remove / rollback / takeover restore packages.lock.json to the nuget.org catalog packageHash, which isn't NuGet's contentHash for signed packages, so every later dotnet restore fails NU1403 #624 follow-up: an unsigned (non-nuget.org-signed) package hash path.
3. Local tools (.config/dotnet-tools.json + dotnet tool restore) in agent mode.
4. Two Socket patches for different ids in one project (needs a second fixture package in the backend stand-in).
5. Interrupted (SIGKILL mid-write) vendored run, then repair.

[github-actions[bot]]

[agent] 2026-10-03 (11:44 UTC): NuGet / dotnet bug-hunt run

Tested: main 045d7ec (unchanged), release v4.0.0 (npm, used to bisect). Local SDK: dotnet 8.0.131 (Ubuntu apt, reinstalled). No probe branch: git push --delete is still denied from the sandbox (unexpected disconnect), so the 5 stale bughunt/nuget/* branches remain and I'm pushing no new ones.

Setup: the scratch_serve harness again (a scratch copy of e2e_nuget_dotnet_build.rs running a bash SCRATCH_SCRIPT against the wiremock Backend). Deleted after the run.

Re-triage

• main hasn't moved, so every open pm:nuget issue stands. Open PR Unify hosted NuGet routing and XML splice anchors #597 ("Unify hosted NuGet routing and XML splice anchors") would fix the hosted <clear></clear> gap below, and it ships a unit test for it.

Cells (Linux, SDK 8.0.131)

• Close tag with whitespace (</packageSources >, </packageSourceMapping >, valid XML that dotnet restores): vendored fail → Vendored NuGet doesn't recognise a close tag with whitespace (</packageSources >, </packageSourceMapping >), so it appends a second section that NuGet ignores and every restore fails NU1100 / NU1403 while scan reports success and VEX attests #685. A duplicate section is appended and NuGet ignores it: NU1100 for packageSources, NU1403 for the mapping. Exit 0 success, and the in-run VEX attests not_affected. Reproduced 2× on main; v4.0.0 is the same. vendor --revert is byte-exact. Hosted pass (a duplicate nuget.org <add> is cosmetic, and restore installs PATCHED).
• Long-form <clear></clear> (NuGet honours it; checked with dotnet nuget list source): hosted fail. The Socket source/mapping goes before the clear, so NU1100 (packageSources) or NU1403 (mapping), while scan reports success. Not filed: open PR Unify hosted NuGet routing and XML splice anchors #597 already handles <clear></clear> (its tokenizer records non-self-closing clears and it adds a test). Vendored pass.
• <clear /> after an existing <add> (old source, clear, nuget.org): hosted and vendored pass. The catch-all also maps * to the cleared old key; NuGet ignores mappings for undefined sources, so it's cosmetic.
• Multi-TFM, same id at two versions (net8.0 → 13.0.3, netstandard2.0 → 12.0.3): hosted silently upgrades netstandard2.0 to 13.0.3 (the locked restore succeeds). Vendored gives NU1102 on every restore. Both exit 0 success. Covered by Hosted NuGet rewrites packages.lock.json entries at other versions of the patched id #593 (arch-audit, unit-test only); I commented with the real-dotnet evidence and corrected its "locked mode refuses" claim for hosted.
• SIGKILL mid-scan (hosted + vendored, 10 delays from 20–330 ms): pass. Torn states seen: hosted config wired but lock not; vendored artifact dir with no wiring. A re-run converges every time, and a fresh locked restore installs PATCHED.
• Vendored repair after the nupkg is deleted or tampered with: pass. vendor_artifact_missing / vendor_artifact_corrupt → redownloaded, byte-identical, locked restore OK.

Issues

• Filed Vendored NuGet doesn't recognise a close tag with whitespace (</packageSources >, </packageSourceMapping >), so it appends a second section that NuGet ignores and every restore fails NU1100 / NU1403 while scan reports success and VEX attests #685: Vendored NuGet doesn't recognise a close tag with whitespace (</packageSources >, </packageSourceMapping >), so it appends a second section that NuGet ignores and every restore fails NU1100 / NU1403 while scan reports success and VEX attests #685
• Commented on Hosted NuGet rewrites packages.lock.json entries at other versions of the patched id #593: Hosted NuGet rewrites packages.lock.json entries at other versions of the patched id #593 (comment)

False positives ruled out

• Hosted <clear></clear>: a real failure, but already covered by open PR Unify hosted NuGet routing and XML splice anchors #597. Not filed.
• Phantom * mapping for a source key that sits before a <clear />: restore is unaffected. Cosmetic.
• nuget.config spelling priority: hosted and vendored both use NuGet's own order (nuget.config, NuGet.config, NuGet.Config). Not a bug.

Next

1. Re-check <clear></clear> once Unify hosted NuGet routing and XML splice anchors #597 lands; check whether Unify hosted NuGet routing and XML splice anchors #597's tokenizer covers vendored too (Vendored NuGet doesn't recognise a close tag with whitespace (</packageSources >, </packageSourceMapping >), so it appends a second section that NuGet ignores and every restore fails NU1100 / NU1403 while scan reports success and VEX attests #685).
2. Other valid-XML spellings in vendored: <packageSources/> with attributes, a xmlns on <configuration>, </configuration >.
3. NuGet scan --mode vendored over a hosted pin skips the takeover (purl case mismatch), keeps the hosted feed wired, writes no vendor ledger and still reports success #553 case sensitivity in vex output purls.
4. Local tools (.config/dotnet-tools.json) in agent mode; two Socket patches for different ids.
5. macOS / Windows and SDK 6/9/10 cells, once probe branches can be deleted.