[DCR]: Mitigate missing nuget.org when non-NuGet tool creates nuget.config without any sources

[zivkan]

NuGet Product(s) Affected

NuGet.exe, Visual Studio Package Management UI, Visual Studio Package Manager Console, MSBuild.exe, dotnet.exe

Current Behavior

If using Chocolatey, or Windows PowerShell's PowerShellGallery (nuget provider), on a clean machine, before running NuGet "proper" (Visual Studio, dotnet cli, nuget.exe, msbuild restore), then the user-profile nuget.config file created will not have any package sources. When a customer later tries to use "real" NuGet, nuget.org appears to not be pre-installed.

Desired Behavior

Starting with a clean machine, install development tools with Chocolatey and PowerShellGallery, then install VS or the .NET SDK, NuGet restore should use nuget.org.

⚠️ Note ⚠️

Customers who satisfy the following criteria:

1. Installed a product with NuGet (such as Visual Studio or the dotnet cli) on a clean machine in 2021
   • Technically, a machine which does not have the file nugetorgadd.trk in the directory with NuGet's user config, which would be any machine that has only used NuGet version 5.10 or higher, or if the file was manually deleted.
2. Intentionally removed nuget.org from their user nuget.config and did not replace it with any other sources, so it does not contain any sources.

These customers will find that nuget.org will be added as a package source one time, and that the file nugetorgadd.trk will be created in that directory.

The mitigation to prevent this is to create an empty file named nugetorgadd.trk in the same directory as the user NuGet.Config before updating to new tools (NuGet.exe, Visual Studio, dotnet CLI), or before using them for the first time.

If NuGet is run after updating to newer tools, then nuget.org will be added to the user NuGet.Config and can be removed again. As long as nugetorg.trk is not deleted, it will not be re-added again.

Additional Context

NuGet has always created the user-profile nuget.config file on first access, when the file doesn't already exist. However, there was a time when it would do so without creating any package sources. Later NuGet was modified to add nuget.org as a package source when the default file was created.

Since NuGet's functionality is available as NuGet packages, other products (most notably Chocolatey and PowerShell's Install-Module NuGet provider) used these packages, but did not update to newer versions of the packages where nuget.org was added by default. Therefore, if these tools were used before Visual Studio, MSBuild.exe, the .NET CLI, or NuGet.exe were used, they would create this nuget.config file without nuget.org as a package source.

This did not cause problems in the past because the implementation of how nuget.org got added to the user-profile file was by checking if a "tracking file" was created. When the tracking file was not on disk, it adds nuget.org as a package source to nuget.config, and creates the tracking file.

In early 2021, a security researcher posted a blog post about supply chain attacks where private libraries (packages in the NuGet/.NET ecosystem) that are internal to a company and therefore are on a private feed, are at risk if someone publishes a package with the same name and version on public feeds (nuget.org in our case). One of the mitigations for this is for companies to mirror the public packages they use in a private feed, and then stop using the public feed.

There, there was a significant number of security conscience customers who were removing nuget.org from their nuget.config. Those customers who did not use tools such as Chocolatey, that created the nuget.config without any package source, before running NuGet in an official tool first, they found that after trying to remove nuget.org as a package source, it would come back. Only by removing nuget.org twice, that nuget.org would finally be removed as a package source. Customers who did not notice this were at risk of the "dependency confusion" attack they tried to mitigate by removing nuget.org as a package source.

The NuGet.Client team changed NuGet to no longer add nuget.org as a package source when the tracking file was missing: NuGet/NuGet.Client#3907

However, it was not known at that time that other tools were creating nuget.config without the package source. Since this version of NuGet has been released in Visual Studio and the .NET SDK, customers who do use those tools were under the mistaken impression that NuGet was not adding nuget.org as a package source by default. One such issue where customers were unaware of other tools creating this file is #10804

[dominoFire]

Similar issue in VSFeedback https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1355557