Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#514 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
76/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
cli, devtools

Rechercherichtung

Start with crates/socket-patch-core/src/vendor/nuget_feed.rs and crates/socket-patch-core/src/patch/redirect/mod.rs, where the hard-coded lock filename is used, then review crates/socket-patch-core/src/vex/discover/nuget.rs. Use the repro based on crates/socket-patch-cli/tests/e2e_nuget_dotnet_build.rs and verify vendored and hosted scans recognize packages..lock.json, repin its contentHash, and leave locked and plain dotnet restore succeeding.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

agent:triaged bug bughunt pm:nuget priority:p3

[agent] Found by the scheduled NuGet / dotnet bug-hunt routine (ledger #320).

Summary

NuGet supports a per-project lock name: when packages.<ProjectName>.lock.json exists beside the project, NuGet reads and writes that file and does not use packages.lock.json (the convention for several projects in one directory, documented in the NuGet docs under "Locking dependencies"). socket-patch only looks for the hard-coded packages.lock.json:

  • Vendored (scan --mode vendored): it reports vendor_nuget_no_lockfile with the message "no packages.lock.json (RestorePackagesWithLockFile is off)". That is false, because the project does have a lock. It wires the folder feed and mapping but leaves packages.app.lock.json pinned to the upstream contentHash. Exit code is 0, and the in-run VEX attests not_affected (vendored).
  • Hosted (scan --mode hosted): it adds the Socket source and the exact-id mapping, reports redirected: 1 with no warning, and leaves the named lock pinned to upstream. Exit code is 0, and the in-run VEX attests not_affected (redirected).

On the next restore, the patched nupkg doesn't match the lock. Every restore of the committed files then fails with NU1403: Package content hash validation failed for Newtonsoft.Json.13.0.3, both --locked-mode and plain dotnet restore.

Impact

Running vendored or hosted mode on such a project breaks its build in CI, and a fresh clone can't restore. The CLI reports success. The vendored warning tells the user the project has no lock, which points them the wrong way. VEX attests a patch the project can't install.

Repro (Linux, .NET SDK 8.0.131)

The repro is a scratch copy of crates/socket-patch-cli/tests/e2e_nuget_dotnet_build.rs, with the same wiremock Backend stand-in for the patch API and the hosted feed, and a real nuget.org fixture restore. The only change is that the fixture's lock is renamed:

# app.csproj: net8.0, RestorePackagesWithLockFile=true, PackageReference Newtonsoft.Json 13.0.3
dotnet restore                                   # writes packages.lock.json
mv packages.lock.json packages.app.lock.json
rm -rf obj && dotnet restore --locked-mode       # OK, and no packages.lock.json is created: NuGet uses the named lock
# sanity: corrupting a contentHash in packages.app.lock.json makes this restore fail NU1403,
# which proves NuGet really reads the named file

socket-patch scan --mode vendored --vendor-source service --json --yes --vex scan.vex.json ...
#   rc 0; vendor result errorCode "vendor_nuget_no_lockfile":
#   "no packages.lock.json (RestorePackagesWithLockFile is off); the vendored feed forces Newtonsoft.Json from the patched copy but its contentHash is not pinned"
#   packages.app.lock.json unchanged; scan.vex.json: not_affected "Patched via Socket patch … (vendored)"

# fresh checkout (app.csproj, nuget.config, packages.app.lock.json, .socket/), cold NUGET_PACKAGES:
dotnet restore --locked-mode   # rc 1: error NU1403: Package content hash validation failed for Newtonsoft.Json.13.0.3
dotnet restore                 # rc 1: same NU1403

The hosted run (scan --mode hosted --patch-server-url <stand-in>) behaves the same way: redirected: 1, warnings: [], the named lock is unchanged, the in-run VEX attests (redirected), and both restores fail NU1403.

Control: the same test with the default packages.lock.json passes. The lock is re-pinned, both restores exit 0, and the patched bytes are installed.

Each case reproduced 2/2 on main 61cfb9b.

Expected vs actual

  • Expected: docs/ecosystems.md (NuGet row and "NuGet locked mode") says vendored and hosted mode pin the patched .nupkg through the lock's contentHash, so a locked restore installs the patched package. When there's no lock, vendored says so with vendor_nuget_no_lockfile. A lock that NuGet actually uses should be re-pinned. If socket-patch can't handle it, it should refuse loudly rather than report success.
  • Actual: the named lock is ignored. Vendored claims there's no lock, hosted says nothing, both exit 0, the build then fails NU1403, and VEX attests.

OS × version

OS SDK vendored hosted
Linux 8.0.131 reproduces reproduces
Linux 8.0.131, default packages.lock.json (control) pass pass
macOS / Windows, SDK 6/9/10 untested (NuGet has supported the named-lock convention since 4.9, so it should be the same)

Not bisected. The lock name is a constant in both writers.

Suspect code

  • crates/socket-patch-core/src/vendor/nuget_feed.rs:33 (const PACKAGES_LOCK: &str = "packages.lock.json"), used at :244 to locate the lock and at :586 for the misleading vendor_nuget_no_lockfile message.
  • crates/socket-patch-core/src/patch/redirect/mod.rs:4413 (rewrite_nuget reads only files.get("packages.lock.json")).
  • crates/socket-patch-core/src/vex/discover/nuget.rs only documents custom NuGetLockFilePath names as a VEX non-goal. The packages.<project>.lock.json convention needs no property, and NuGet picks it up automatically.
Vorherrschende Sprache
Rust
Sterne
8
Forks
0
Ø Merge
19 Std. 21 Min.
Gemergte PRs (30 T.)
421

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SocketDev/socket-patch

Alle Issues in SocketDev/socket-patch

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.