Bug hunt ledger: NuGet / dotnet #320

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

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

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

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