NuGet vulnerability warnings with Visual Studio 2022 17.12

[ContentsMayVary]

Having upgraded to Visual Studio 2022 17.12 today, we are now getting NuGet vulnerability warnings for this package.

To reproduce:

Add the following NuGet package reference to a netstandard2.0 project:

<PackageReference Include="StreamJsonRpc" Version="2.20.17" />

When you compile that project with Visual Studio 2022 17.12 you get the following warnings:

warning NU1902: Package 'MessagePack' 2.5.108 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-4qm4-8hg2-g2xm
warning NU1903: Package 'System.Text.Json' 8.0.3 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4
warning NU1903: Package 'System.Text.Json' 8.0.3 has a known high severity vulnerability, https://github.com/advisories/GHSA-hh2w-p6rv-4g7w

[Andrey-2021]

Additionally.
After update Microsoft Visual Studio Community 2022 to version 17.12.0

I can't setup nuget packages.
When I trying setup packege,
I have error:
CACHE https://api.nuget.org/v3-vulnerabilities/2024.11.12.12.02.33/2024.11.14.05.25.25/ vulnerability.update.json
And the NuGet window freezes

---

I have solved my problem

1. I Deleting %AppData%\Roaming\NuGet\NuGet.Config
   as recommended here
   https://stackoverflow.com/questions/41185443/nuget-connection-attempt-failed-unable-to-load-the-service-index-for-source

But that didn't solve the problem.
Maybe you shouldn't have deleted it.

2. Clearing all local folders
   as recommended here
   https://learn.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders#clearing-local-folders

After that, the NuGet packages began to be installed

[dotnetjunkie]

This new warning is a problem. Although developers should of course strive to upgrade packages to later, safe packages, this isn't always possible. I find myself, for instance, regularly switching to older branches in order to reproduce and analyze reported bugs. But now I find myself in the situation where those older branches stopped compiling, because we enabled 'warnings as errors' in our projects, while these older branches don't reference the newest NuGet packages, as they didn't exist at that time.

Although the specific NuGet rules 1901, 1902, and 1903 can be excluded in the config file from the 'warnings as errors' list, this is quite some work in a solution with almost 70 projects. Likewise is it quite some work to upgrade the NuGet vulnerable packages in those older branches, and it makes no sense to do that just for the sake of bug analysis.

There might be an easy way to disable this new feature, but unfortunately, the error message isn't clear about this.

Please make it easier for a developer to understand how to disable this change in the IDE and revert back to the old behavior (where we already got a clear warning in the Solution Explorer).

[ContentsMayVary]

@dotnetjunkie : There is a way to fix this: You have to explicitly reference a later bug-fixed version of the offending transient NuGet packages wherever you are referencing the StreamJsonRpc package. For example:

<PackageReference Include="StreamJsonRpc" Version="2.20.17" />
<PackageReference Include="MessagePack" Version="2.5.192" />
<PackageReference Include="System.Text.Json" Version="8.0.5" />

[dotnetjunkie]

@ContentsMayVary, but that was exactly my point: you don't always want to make changes to the package references, or anything else, when checking out older branches or older commits, as this can severely impact your efficiency as a developer. If such checked-out commit compiled one years ago, it must compile today.

For instance, I use GIT's bisect to find which commit introduced a bug. Bisect jumps through commits using a binary tree, but after it checked out a commit, you must be able to compile your code in order to run it. As long as these warnings can't be easily suppressed (which they probably can, but the error message doesn't help us in this regard), GIT's bisect (or any similar way of working with older commits) becomes very inefficient.

[ContentsMayVary]

@dotnetjunkie I'm not sure if this will be of any use, but you can change the errors back into warnings for an entire build by adding a "directory.build.props" file to the same folder as the base ".proj" file with the following contents:

<Project>
  <PropertyGroup>
    <WarningsNotAsErrors>NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors>
  </PropertyGroup>
</Project>

[dotnetjunkie]

Thanks for the information. Unfortunately, this won't really help when checking out older commits.

[baywet]

Hi everyone,
We're seeing similar behaviours in kiota.

I've put together #1094 to address the system.text.json advisories.

For message pack, this is strange since @AArnott authored #1086 which locally resolves to 2.5.187.
But the nuget dependencies tab still shows >= 2.5.108 which is the source of the warning for the consumers.
The only explanation here I can come up with is that the release was somehow triggered before that change?? I hope Andrew can help clarify what happened here.

Lastly, as a workaround, you should be using NugetAuditSuppress instead of blanket error code suppressions, so you're aware of any future advisories on your projects. Example

[RyanToth3]

It looks like there is a pipeline issue right now that's preventing the version of this package with the fixed reference from being released. @baywet resolved the vulnerable System.Json.Text reference and I'm currently looking into getting the pipeline back up and running.

[RyanToth3]

We have the fix for this ready to release at the same time as 1712.2. We'll update this issue once the package is live.

[ekoppel]

The package containing the fix has been published to nuget - StreamJsonRpc 2.20.20.