Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Vendored NuGet on a core.autocrlf checkout: vendor --revert / remove / rollback revert packages.lock.json but leave nuget.config wired, so every restore fails NU1403 (vendor --revert exits 0)

Aberta
  • Algo errado?
#537 1 comentário 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
45/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
git, rust
Domínio
build-system, cli

Direção de pesquisa

Start with the NuGet revert flow in crates/socket-patch-core/src/vendor/nuget_feed.rs, especially lines 728, 1180, 1206, and 1236. Run the reproduction in crates/socket-patch-cli/tests/e2e_nuget_dotnet_build.rs with a core.autocrlf=true checkout. Done means each revert path keeps the project restorable and reports an accurate result when nuget.config is CRLF-converted.

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

Vendored NuGet writes nuget.config with LF line endings and records the exact text it wrote. When the project is committed and then checked out with core.autocrlf=true (Git for Windows' default, and common on any OS), nuget.config and packages.lock.json come back with CRLF. On that checkout, every revert path ends up half-done:

  1. The lock record is reverted first (revert_nuget_opts walks the wiring in reverse order). It's a JSON string swap, so CRLF doesn't affect it, and packages.lock.json goes back to the upstream contentHash.
  2. Then the config record is reverted. The whole-file fast path compares the live text with the recorded LF text, and the fallback excision looks for LF-terminated fragments (" <add key=\"…\" value=\"…\" />\n" and " <packageSource key=\"…\">\n"). Neither matches CRLF, so the config is treated as drifted and left wired (vendor_lock_entry_drifted), and the artifact is kept.

The result is a project whose lock pins upstream bytes while nuget.config still maps Newtonsoft.Json exclusively to the vendored feed. Every later dotnet restore, locked or not, fails with NU1403: Package content hash validation failed.

  • vendor --revert exits 0 with status: success.
  • remove <purl> exits 1 and says "every matching entry's vendored state drift-kept; nothing was removed". But it did rewrite packages.lock.json.
  • rollback exits 1 (partial_failure), and it also rewrites the lock.
  • The suggested remedy doesn't help. Re-running scan --mode vendored, as vendor_revert_kept advises, reports already_vendored / "artifact and lockfile wiring already in sync", and the next vendor --revert half-reverts again.
  • vendor --check on the same checkout reports vendor_check_ok.

Impact

A Windows developer, or anyone using autocrlf=true, who clones a vendored NuGet project and tries to un-vendor it gets a project that no longer restores. vendor --revert reports success while doing it. The only way out is to fix the lock or config by hand, or to git checkout both files. There's nothing for the user to "undo", because the only drift is git's line-ending conversion of a file socket-patch itself committed.

Repro (Linux / macOS / Windows, any SDK)

I drove this with a scratch copy of crates/socket-patch-cli/tests/e2e_nuget_dotnet_build.rs: the same wiremock Backend stand-in, a real nuget.org fixture restore, and the real dotnet.

# app.csproj: net8.0, RestorePackagesWithLockFile=true, PackageReference Newtonsoft.Json 13.0.3
# nuget.config: nuget.org only (LF)
dotnet restore
socket-patch scan --mode vendored --vendor-source service --json --yes ...   # rc 0; lock re-pinned, feed + mapping wired
git init && git add -A && git commit -m vendored

git clone -c core.autocrlf=true <repo> wc && cd wc      # what Git for Windows does by default
file nuget.config                                         # "... with CRLF line terminators"
dotnet restore --locked-mode                              # rc 0, PATCHED LICENSE.md installed (baseline ok)

socket-patch vendor --revert --json
#   rc 0, "status": "success"
#   events: skipped vendor_lock_entry_drifted "nuget.config no longer carries what vendor wrote for socket-patch-<uuid>; left alone"
#           skipped vendor_artifact_kept, skipped vendor_revert_kept
git status --short        #  M packages.lock.json      (lock reverted to the upstream contentHash)
grep -c socket-patch nuget.config                         # 2 (source + mapping still there)
rm -rf obj && 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

remove pkg:nuget/[email protected] (rc 1, vendor_revert_kept "nothing was removed") and rollback (rc 1) leave exactly the same state: lock modified, config wired, NU1403. Running scan --mode vendored first and then vendor --revert behaves the same way.

Control: on the same commit cloned without autocrlf, vendor --revert restores both files byte-for-byte and the locked restore installs the pristine package.

Expected vs actual

  • Expected: CLI_CONTRACT.md says vendor --revert "restores the originals". Drift-keep is for fragments "that no longer match — a user re-resolved", and it should keep the project restorable. The contract already treats a checkout's line-ending conversion as something revert must survive for cargo ("remove / rollback match the recorded fragments across a later CRLF↔LF checkout conversion"). The minimum is that a revert which keeps the config wired must not revert the lock pin on its own, and must not report success / "nothing was removed".
  • Actual: a git line-ending conversion counts as drift. The lock is reverted anyway, the config isn't, and the project can't restore.

OS × version (probe run, all with git clone -c core.autocrlf=true)

OS SDK vendor --revert remove rollback rescan → revert
Linux (sandbox) 8.0.131 repro (rc 0) repro (rc 1) repro (rc 1) repro
ubuntu-latest 8.0.x, 10.0.x repro repro repro repro
macos-latest 8.0.x repro repro repro repro
macos-latest 10.0.x job ran; I only inspected the named-lock cells in its log
windows-latest (Git for Windows, system autocrlf=true) 8.0.x, 10.0.x repro repro repro repro
any any, no autocrlf (control) pass pass pass pass

Reproduced 3× in the sandbox on main 61cfb9b, and on every probe cell: https://github.com/SocketDev/socket-patch/actions/runs/36970426074

Not bisected. The LF-anchored fragments in the NuGet revert look as old as the vendored NuGet backend.

Suspect code

  • crates/socket-patch-core/src/vendor/nuget_feed.rs:1180: the whole-file fast path w.new == live is exact-byte.
  • crates/socket-patch-core/src/vendor/nuget_feed.rs:1206 and :1236: the excision fragments are hard-coded with \n (source_add, excise_source_mapping), so a CRLF file always falls to Ok(false) at :1210.
  • crates/socket-patch-core/src/vendor/nuget_feed.rs:728: the reverse-order loop reverts the lock record before the config record and doesn't undo it when the config is drift-kept. That turns a "left alone" into a broken half-revert.
  • The vendored nupkg itself is untouched by autocrlf, because git detects it as binary. Vendor writes no .gitattributes for nuget.config / packages.lock.json; compare #429, the Gradle counterpart of this autocrlf class.
Linguagem predominante
Rust
Estrelas
8
Forks
0
Merge médio
22h 30min
PRs com merge (30d)
329

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.