Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do 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

Aberta
  • Algo errado?
#514 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
76/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
cli, devtools

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Rust
Estrelas
8
Forks
0
Merge médio
1d 1h
PRs com merge (30d)
257

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de SocketDev/socket-patch

Todas as issues de SocketDev/socket-patch

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.