-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable NuGet Audit #15018
Enable NuGet Audit #15018
Conversation
First vulnerability warning:
We don't directly reference that package so I did the following to find out where it's coming from: @ViktorHofer ➜ /workspaces/arcade (ViktorHofer-patch-1) $ ./.dotnet/dotnet nuget why src/VersionTools/Microsoft.DotNet.VersionTools.Tasks/Microsoft.DotNet.VersionTools.Tasks.csproj Microsoft.IO.Redist
Project 'Microsoft.DotNet.VersionTools.Tasks' has the following dependency graph(s) for 'Microsoft.IO.Redist':
[net472]
│
├─ Microsoft.Arcade.Common (v9.0.0-dev)
│ └─ Microsoft.Build.Utilities.Core (v17.8.3)
│ └─ Microsoft.IO.Redist (v6.0.0)
├─ Microsoft.Build.Tasks.Core (v17.8.3)
│ ├─ Microsoft.Build.Utilities.Core (v17.8.3)
│ │ └─ Microsoft.IO.Redist (v6.0.0)
│ └─ Microsoft.IO.Redist (v6.0.0)
└─ Microsoft.DotNet.VersionTools (v9.0.0-dev)
└─ Microsoft.Arcade.Common (v9.0.0-dev)
└─ Microsoft.Build.Utilities.Core (v17.8.3)
└─ Microsoft.IO.Redist (v6.0.0)
[net9.0]
│
└─ No dependency graph(s) found for this target framework. So that package is a dependency of Microsoft.Build.Utilities.Core/17.8.3 which we directly reference. Nuget.org tells us that Microsoft.IO.Redist/6.0.1 is already available but a newer Microsoft.Build.Utilities.Core package with that updated dependency isn't. That means we need to pin the transitive dependency to the higher version. "Luckily (it was me) Arcade already uses Central Package Management (CPM) so we can easily do that. See commit 2. |
I think I got this one just now! a3756ed |
acc4cd0
to
4fe8a46
Compare
Second vulnerability warning:
That warning only shows up for MSBuild task projects or dependencies of it. @ViktorHofer ➜ /workspaces/arcade (ViktorHofer-patch-1) $ ./.dotnet/dotnet nuget why src/Microsoft.DotNet.Helix/Client/CSharp/Microsoft.DotNet.Helix.Client.csproj System.Text.Json
Project 'Microsoft.DotNet.Helix.Client' has the following dependency graph(s) for 'System.Text.Json':
[net472]
│
└─ Azure.Core (v1.41.0)
├─ System.ClientModel (v1.0.0)
│ ├─ System.Memory.Data (v1.0.2)
│ │ └─ System.Text.Json (v8.0.0)
│ └─ System.Text.Json (v8.0.0)
├─ System.Memory.Data (v1.0.2)
│ └─ System.Text.Json (v8.0.0)
└─ System.Text.Json (v8.0.0)
[net9.0]
[netstandard2.0]
│
└─ Azure.Core (v1.41.0)
├─ System.ClientModel (v1.0.0)
│ ├─ System.Memory.Data (v1.0.2)
│ │ └─ System.Text.Json (v9.0.0-preview.6.24327.7)
│ └─ System.Text.Json (v9.0.0-preview.6.24327.7)
├─ System.Memory.Data (v1.0.2)
│ └─ System.Text.Json (v9.0.0-preview.6.24327.7)
└─ System.Text.Json (v9.0.0-preview.6.24327.7) So, only the .NET Framework side is impacted, interesting. This is because MSBuild .NET Framework tasks can't go higher than what's defined by the binding redirects. See arcade/eng/BuildTask.Packages.props Line 11 in a3756ed
Looking at https://github.com/dotnet/msbuild/blob/b5fcc152e1df4023af8b8e7317e29d263beeeaa8/src/MSBuild/app.config#L97 we can see that binding redirects for the non-vulnerable version (8.0.4) already exist. What is unfortunate here is that this change happened only a month ago and so we can't yet rely on it as by doing so, we would require a very recent version of MSBuild (probably a dogfood build of 17.12). That effectively means that we can't yet upgrade to the non-vulnerable 8.0.4 version. So we need to suppress this advisory (and later in Component Governance again) and defer the upgrade by ~1 month when a newer version of VS with the updated .NET Framework MSBuild is consumed. See commit 3. |
They can if you're willing to redist the assembly next to your task, and in fact it looks like |
No we should not do this. Tasks should not upgrade the host. We should not carry a new assembly that we don't even use. One trick we could use for this now, in lieu of an actual MSBuild task SDK would be to reference the MSBuild assemblies via PackageDownload. That would minimize the dependency closure of theirs that we bring in, while still getting the references to MSBuild we actually need. |
Yes, you are correct. That's a bug in the msbuild tasks package authoring here in Arcade: Lines 33 to 84 in a3756ed
It only excludes direct package dependencies, not transitive ones. Unsure how to fix this, though. Filed #15022 |
Should we add WarningsNotAsErrors like @zivkan mentioned in #15019 (comment) so that the build doesn't break on patch-Tuesday? I know we used to have that characteristic with harvesting (build breaks when new packages are published) and it had a lot dissatisfaction from developers. It's tough though, because we also want high-visibility of these. |
Let's not add If this starts to significantly disturb our product composition, we can always go back and add cc @mmitche for opinions |
Before I merge this PR I would like to get an explicit ack that this strategy is ok. As mentioned we can always change direction if necessary. |
I had a chat with @akoeplinger and he convinced me that promoting NuGetAudit warnings to errors by default is too noisy and could halt productivity. I adjusted the code path to only fail official builds to guarantee that we aren't producing official bits without NuGetAudit enabled. In all other cases (dev & PR) NuGetAudit will emit warnings. |
Filed #15031 to track upgrading STJ to 8.0.4 |
See #15019
To double check: