Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue 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

Đang mở
  • Có gì không ổn?
#514 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
76/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
cli, devtools

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Rust
Star
8
Fork
0
Merge trung bình
1 ngày 7 phút
Pull request đã merge (30 ngày)
178

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SocketDev/socket-patch

Tất cả issue của SocketDev/socket-patch

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.