Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#514 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
cli, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Rust
Estrellas
8
Forks
0
Merge medio
1 d 1 h
PR fusionados (30 d)
211

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de SocketDev/socket-patch

Todos los issues de SocketDev/socket-patch

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.