error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xhfc-gr8f-ffwc

[noraa-junker]

Describe the bug

Every project I tried to build using the current Visual Studio Preview version throws this error. System.Private.Uri is not a directly included project. I also tried clearing all nuget data, but it didn't help. In the stable Visual Studio version it works.

To Reproduce

1. Create a new c# project of any kind (.net 8)
2. Try to build it
3. It fails

Exceptions (if any)

1>K:\PowerToys\src\modules\FileActionsMenu\FileActionsMenu.Helpers\FileActionsMenu.Helpers.csproj : error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-5f2m-466j-3848
1>K:\PowerToys\src\modules\FileActionsMenu\FileActionsMenu.Helpers\FileActionsMenu.Helpers.csproj : error NU1902: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-x5qj-9vmx-7g6g
1>K:\PowerToys\src\modules\FileActionsMenu\FileActionsMenu.Helpers\FileActionsMenu.Helpers.csproj : error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xhfc-gr8f-ffwc

Further technical details

• Dotnet --info output:

.NET SDK:
 Version:           8.0.303
 Commit:            29ab8e3268
 Workload version:  8.0.300-manifests.c915c39d
 MSBuild version:   17.10.4+10fbfbf2e

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26257
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Users\aaron\AppData\Local\Microsoft\dotnet\sdk\8.0.303\

.NET workloads installed:
There are no installed workloads to display.

Host:
  Version:      8.0.7
  Architecture: x64
  Commit:       2aade6beb0

.NET SDKs installed:
  8.0.303 [C:\Users\aaron\AppData\Local\Microsoft\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.7 [C:\Users\aaron\AppData\Local\Microsoft\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.7 [C:\Users\aaron\AppData\Local\Microsoft\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 8.0.7 [C:\Users\aaron\AppData\Local\Microsoft\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

• Visual Studio 17.11 Preview 7.0

[martincostello]

This is due to changes to NuGet: https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/

The package will be a transient dependency of something in your dependency graph.

Using the .NET 9 preview 6 SDK you can use the new dotnet nuget why command to find its origin.

[noraa-junker]

This is due to changes to NuGet: https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/

The package will be a transient dependency of something in your dependency graph.

Using the .NET 9 preview 6 SDK you can use the new dotnet nuget why command to find its origin.

This does not work it just says Project '...' does not have a dependency on 'System.Private.Uri'.

[martincostello]

That's a different issue then if dotnet nuget why isn't finding it in the graph.

It will be a dependency of something in your dependency graph - trivy scan found it in various container images of mine prior to the NuGet updates, which I had to fix (e.g. martincostello/api@ff08bd2).

You can try looking in the .deps.json file of your published project to find what dependency is bringing it in.

[marcpopMSFT]

@aortiz-msft @JonDouglas for why dotnet nuget why didn't find the dependency. Should we ask the customer to file this in the nuget repo instead?
@richlander @agocke for guidance on how to track these down. In this case, I'd look in the deps.json file or the project.assets.json file looking for System.Private.Uri and try to trace back it's dependency tree.

[aortiz-msft]

@aortiz-msft @JonDouglas for why dotnet nuget why didn't find the dependency. Should we ask the customer to file this in the nuget repo instead?

Yes please.

[DanTravison]

IMHO: The tooling for this needs work!

Last night I upgraded VS Enterprise to 17.11.0 and VS Community Preview to 17.12.0 Preview 1.0 and hit this on the first Maui application I built.

I ended up running dotnet restore against a number of my solutions to find it impacted most of my Maui applications.

At first, I thought I needed to add a PackageReference to each application project to resolve it. In the end, the suggestion to search project.assets.json finally narrowed it down to one of my shared assembly's.

What I didn't see was the error for the shared assembly that was the root cause of the problem.

To me, there are two bugs:
1: dotnet restore should report the security vulnerability for the shared assembly.
2: the build should have an option to fail on security vulnerabilities. My builds succeeded.

Thanks.

[aortiz-msft]

@DanTravison - Thank you for the feedback!

For the first issue, would you mind opening an issue at https://github.com/NuGet/Home/issues/new/choose with reproducible steps? We'd be happy to take a look!

For the second issue, you can configure the SDK to treat all or certain warnings as errors: https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings. If you feel that the default for vulnerabilities should be error, let us know that too.

cc @zivkan

[DanTravison]

For the first issue, I created NuGet/Home#13708

For the second issue, I cannot get the build to fail for the vulnerability issue.

I've tried WarningsAsErrors, with Warning Level 1, 7, and All Warnings and don't see the warning promoted to an error.
VS is using Nuget 6.11.0.

Here's an example output I'm expecting to see promoted:
1>C:\git\travison\Maui.Core\Maui.Core\Maui.Core.csproj : warning NU1900: Error occurred while getting package vulnerability data: Unable to load the service index for source https://api.nuget.org/v3/index.json.
1>Done building project "Maui.Core.csproj".

As far as considering this an error, personally, I would prefer that so I don't have to change every project to enforce it.
I do expect others to disagree, though.

Is there any way to configure this system-wide instead of per-project?

[martincostello]

You could set TreatWarningsAsErrors=true as an environment variable, then it should be picked up by every build and cause the build to fail if there are vulnerable packages.

I set TreatWarningsAsErrors=true in Directory.Build.props in the root of each of my repos, and when the vulnerability in the System.Text.Json prior to 8.0.4 package was published a lot of my builds broke and I had to update it to fix them.

[zivkan]

For the second issue, I cannot get the build to fail for the vulnerability issue.

My guess is that you're using nuget.exe to restore the project. I'm not sure that NuGet.exe supports WarningsAsErrors and TreatWarningsAsErrors. You should use dotnet restore instead. If you have any projects in the solution that can't be restored & built with dotnet, then use msbuild -t:restore. If you have any old projects still using packages.config, use msbuild -t:restore -p:RestorePackagesConfig=true. NuGet.exe is an "old" way of doing things, since before PackageReference was added in 2016 (although restoring packages.config projects via msbuild was implemented months/years later)

However, if you are using dotnet restore or msbuild -t:restore, then it should work, and we'll need more details (preferably a sample solution with a sample command line) to investigate.

[DanTravison]

I am building in Visual Studio (Ent) 17.11.0 and the above warning was from the VS Output window.

Unfortunately, now I can't even get the warning to appear in the VS build output.

I typically run dotnet restore when I change NuGet dependencies because I find restore is unreliable when run as part of the VS build. In fact, I don't even see a warning when I remove the workaround from the shared assembly, clean the solution, and rebuild the solution in VS. The build output shows dotnet restore being run for each project with no warnings and the build completes even though project.assets.json for the Maui application references "System.Private.Uri": "4.3.0"

In comparison, if I clean the solution and run the command-line dotnet restore from the solution directory, I see three warnings for the application project both before and after building in VS.

PS C:\git\travison\Maui.Core> dotnet restore
Restore succeeded with 3 warning(s) in 11.8s
warning NU1903: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, GHSA-5f2m-466j-3848
warning NU1902: Package 'System.Private.Uri' 4.3.0 has a known moderate severity vulnerability, GHSA-x5qj-9vmx-7g6g
warning NU1903: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, GHSA-xhfc-gr8f-ffwc

[ProbablePrime]

I am also experiencing this.
dotnet --info

.NET SDK:
 Version:           9.0.100-rc.1.24452.12
 Commit:            81a714c6d3
 Workload version:  9.0.100-manifests.a7bf2b8f
 MSBuild version:   17.12.0-preview-24422-09+d17ec720d

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100-rc.1.24452.12\

.NET workloads installed:
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: VS 17.11.35303.130
   Manifest Version:    8.1.0/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.1.0\WorkloadManifest.json
   Install Type:              Msi


Host:
  Version:      9.0.0-rc.1.24431.7
  Architecture: x64
  Commit:       static

.NET SDKs installed:
  2.1.403 [C:\Program Files\dotnet\sdk]
  6.0.401 [C:\Program Files\dotnet\sdk]
  7.0.101 [C:\Program Files\dotnet\sdk]
  8.0.100 [C:\Program Files\dotnet\sdk]
  8.0.400 [C:\Program Files\dotnet\sdk]
  9.0.100-rc.1.24452.12 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0-rc.1.24452.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0-rc.1.24431.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0-rc.1.24452.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

And dotnet nuget why, reports the same as Aaron so dotnet nuget why .\<SolutionName>.sln System.Private.Uri -> does not have a dependency on 'System.Private.Uri'.

Perusing through the .deps.json as suggested I find a few references to it:

"runtime.any.System.Runtime/4.3.0": {
        "dependencies": {
          "System.Private.Uri": "4.3.0"
        }
      },
....
"runtime.unix.System.Runtime.Extensions/4.3.0": {
        "dependencies": {
          "System.Private.Uri": "4.3.0",
          "runtime.native.System": "4.3.0",
          "runtime.native.System.Security.Cryptography.OpenSsl": "4.3.0"
        }
      },

Both of these occurrences, initially seem beyond my control as they're located in stuff I've never really touched before, but I may be mistaken.

As it stands, this is a very confusing situation, however as I'm running on a RC, some jank is to be expected.