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-02 11:44 UTC, main 61cfb9b, 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).

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). 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. 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), and 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 vendor --revert <purl>, --package, vex.
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. The probe harness from 2026-10-02 works for this: scratch_serve plus SCRATCH_SCRIPT, inlined through heredocs.
2. 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 (same harness).
3. Local tools (dotnet-tools.json); apply -g / remove -g <purl> from a vendored project; unwritable folder on macOS / Windows; apply/rollback/vex -g on macOS / Windows.
4. Mapping edge cases: a prefix pattern on another source (expect pass), a case-variant exact id, and two Socket patches for different ids.
5. Vendored/hosted with packages.config (windows-latest probe with nuget.exe).
6. 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; unicode / space paths and Windows long paths.
7. Probe-branch cleanup: deleting branches is blocked from the sandbox, so 5 bughunt/nuget/* branches are still on the remote and need a maintainer.

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, and rollback -g alone from a v5 vendored project (no manifest → refused, nothing touched).

Known non-bugs

• Hosted maven/nuget per-purl rollback is refused (hosted_revert_unsupported, CLI_CONTRACT.md). This is documented.
• 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.

[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.