socket fix (NuGet, CPM + lock files): a valid fix is reported as failed because unrelated projects sharing Directory.Packages.props are checked for the package

Aberta
  • Algo errado?
#1,674 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
55/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
node.js, typescript
Domínio
backend, cli

Direção de pesquisa

Start by tracing the NuGet upgrade and lock-file validation path implicated by the reported change to projects sharing Directory.Packages.props; the payload does not name source files or tests. Check how projects selected for restore are distinguished from projects whose lock files contained the vulnerable package before the upgrade. Done means unrelated projects no longer cause a successful fix to fail, while projects that previously contained the vulnerable version still require validation.

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

Descrição

Summary

With Central Package Management (CPM), socket fix upgrades the PackageVersion in Directory.Packages.props, then checks the lock file of every project that imports that file, including projects that do not depend on the upgraded package at all. Those projects fail with <package> is locked at no version after the upgrade to <version>, so a correct fix is reported as failed and the run exits non-zero.

This only happens when lock files are used (RestorePackagesWithLockFile / packages.lock.json): projects without a lock file are not checked after the upgrade.

Environment

Component Version
Socket CLI 1.12.1
Coana CLI (bundled) 15.13.3
OS WSL2, Debian GNU/Linux 12 (bookworm), kernel 5.15.133.1-microsoft-standard-WSL2
Node.js / npm v23.11.1 / 10.9.2
.NET SDK 10.0.403, no global.json

Attachment

socket-nuget-cpm-shared-props-repro.zip:

Directory.Packages.props
A/A.csproj
A/packages.lock.json
B/B.csproj
B/packages.lock.json

Directory.Packages.props:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="12.0.3" />
  </ItemGroup>
</Project>

A/A.csproj (uses the package):

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
  </ItemGroup>
</Project>

B/B.csproj (no package at all):

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
  </PropertyGroup>
</Project>

The lock files were generated by dotnet restore: A/packages.lock.json contains Newtonsoft.Json 12.0.3, B/packages.lock.json has an empty net10.0 section.

Steps to reproduce

unzip socket-nuget-cpm-shared-props-repro.zip && cd socket-nuget-cpm-shared-props-repro
git init && git add -A && git commit -m repro   # only to see the diff afterwards
socket fix . --all
echo "exit=$?"
git diff

Expected

Newtonsoft.Json is upgraded to 13.0.1 (GHSA-5crp-9r3c-p9vr) in Directory.Packages.props and A/packages.lock.json. B is not checked for Newtonsoft.Json, since it never depended on it. The run succeeds with exit code 0.

Actual

info: Upgrading purls for .../socket-nuget-cpm-shared-props-repro:
        pkg:nuget/[email protected] → 13.0.1
debug: Running command: dotnet restore .../A/A.csproj --force-evaluate -p:RestoreLockedMode=false -p:NuGetAudit=false
debug: Running command: dotnet restore .../B/B.csproj --force-evaluate -p:RestoreLockedMode=false -p:NuGetAudit=false
info: ✅ Patch applied ─ Directory.Packages.props
info: ✅ Locked newtonsoft.json 13.0.1 ─ A/packages.lock.json
info: ❌ newtonsoft.json is locked at no version after the upgrade to 13.0.1 ─ B/packages.lock.json
debug: Error stack: UpgradePurlPartialError: Some workspaces failed to upgrade
2/3 workspaces were upgraded successfully.
✖  Coana command failed (exit code 2): command failed

Exit code 1. The changes to Directory.Packages.props and A/packages.lock.json are correct, but the run is reported as failed because of B.

Impact

Any CPM repository with several projects sharing Directory.Packages.props gets one failure per project that does not use the upgraded package. On a real 48-project CPM solution, 22 projects that never depend on the upgraded package failed this way in a single run. Real failures cannot be told apart from this noise, and the non-zero exit code makes the command unusable as a CI gate.

Analysis

After a shared file such as Directory.Packages.props is patched, Coana restores and checks the lock file of every project that reads that file, with the upgraded package as the expected entry. This looks related to the 15.11.3 change "NuGet: projects sharing a changed props file get their lock files updated too". Updating those lock files is correct; requiring the upgraded package to be present in each of them is not.

With CPM and transitive pinning, the pinned PackageVersion applies to every project whose graph contains the package, and only to those. After dotnet restore --force-evaluate, the lock file therefore already reflects the truth: the package is locked at the pinned version where it is used, and absent where it is not. A successful restore is enough; requiring the package to be present in every lock file is both redundant for affected projects and wrong for unaffected ones.

Suggested fix

After dotnet restore --force-evaluate, trust NuGet's resolution instead of requiring the target version in every lock file:

  • A project passes if its lock file no longer contains the vulnerable version (whether the package is now locked at the pinned version or not present at all).
  • For projects that are only restored because they import the changed props file, a successful restore is enough. With CPM transitive pinning, the pinned PackageVersion already applies to every project whose graph contains the package.
  • Keep requiring the target version only for projects whose lock file contained the vulnerable version before the upgrade (this still catches cases where the pin has no effect, such as a VersionOverride or a conditional PackageVersion).
Linguagem predominante
TypeScript
Estrelas
335
Forks
74
Merge médio
1d 11h
PRs com merge (30d)
86

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-cli

Todas as issues de SocketDev/socket-cli

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

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