-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[Bug]: How msbuild tasks should handle CVE-2024-38095? #10656
Comments
What I've done in runtime is cherry-pick the MSBuild assemblies when building tasks. This allows us to reference them without bringing in the closure. https://github.com/dotnet/runtime/pull/107639/files#diff-31e8e6d63141c9dcbc8ed1c2b019b92b199f2902d1856108c7effe8805542789R4 It's a temporary solution until we can get a better one like an MSBuild Task SDK, or some dedicated MSBuild task package. microsoft/MSBuildSdks#551. I think it's possible for MSBuild to produce separate packages just for tasks that might even be version agnostic as the surface area needed by a task rarely changes. |
@jaredpar most folks don't actually use
That upgrades the version to one that's not vulnerable and prevents the task from seeing the higher version and potentially breaking out of the version from VS / MSBuild. Since the package is entirely excluded the project upgrading it cannot witness the upgrade (for example as an assembly reference) - but it does prevent the vulnerable version from being pulled by NuGet. |
Will the package still be downloaded? If so won't that still cause CG alerts that look at disk assets to be triggered? |
The new package would be downloaded, avoiding the CVE alert. In the above sample, I expect SystemFormatsAsn1Version to be set to the fixed version. Typically folks don't persist the MSBuild reference for tasks (using |
Another recommendation here -- try to remove your dependency on I suspect most people don't need this package reference. It's mostly implementation Tasks - that's why it has heavy / highly-serviced dependencies. There are a couple of non task types in here. I wonder if we could push those down to make it easier on folks? Looking through all the types, these ones seem to be the types that aren't actual tasks and could be useful to push down.
Not generally useful nor exchange:
For reference, here's the API surface of Microsoft.Build.Tasks.Core. |
Not realistic for roslyn. That assembly contains the |
Yeah, and even so - that doesn't help with CVE-2024-38081 (Microsoft.IO.Redist) which is similar. I think the best option right now is |
Issue Description
When building with NuGet audit enabled, MSBuild tasks targeting .NET Core will receive the following error:
Looking at a
dotnet nuget why
of the package and will end up with the following:From the perspective of a MSBuild task I'm not sure how we can address this. This package comes from the .NET runtime. There is no way for us to really fix this at the msbuild task level given that the MSBuild host controls this dependency. Not sure how we can proceed here as we can't suppress this warning over the long term.
Steps to Reproduce
Create a new console project and add the following NuGet.config file
Then run the following:
That will produce the following warning:
Expected Behavior
No warning or a method of correctly addressing the warning in the library
Actual Behavior
That will produce the following warning:
Analysis
N/A
Versions & Configurations
No response
The text was updated successfully, but these errors were encountered: