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

Ouverte
  • Quelque chose ne va pas ?
#1,674 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
55/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
node.js, typescript
Domaine
backend, cli

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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).
Langage dominant
TypeScript
Étoiles
336
Forks
72
Merge moyen
1 j 12 h
PR mergées (30 j)
87

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-cli

Toutes les issues de SocketDev/socket-cli

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.