Support "Supplied by Platform" scenario in restore #7344
Comments
|
We can possibly represent this more generally than "supplied by platform". It is almost like a PackageReference with ExcludeAssets="All", but since we won't be taking any assets, then we shouldn't need to pick a version. |
|
@nguerrera I think we would want to supply a version for these packages. IE, .NET Core 3.0 might include System.Collections.Immutable 1.6.0, so we could specify that package as "Supplied by platform", but we wouldn't want to exclude a later version (ie 1.7.0) from the graph if it was encountered. |
|
See the uptick in discussion on dotnet/sdk#3044 and https://github.com/dotnet/core-setup/issues/6222 As we concluded in our last meeting, there's no viable workaround left for SDK on this. We deferred it based on data that suggested it would not be common. The fact that there have been more reports suggests this should be revisited. |
|
Bump? |
|
@rrelyea @dsplaisted More customer pressure on dotnet/sdk#3044. I suspect we'll see even more as 3.0 rolls out. Can we now move past the "do we need to do this?" and start talking about getting this work on the schedule and designing the feature? |
|
Bump. Just hit this again and would really like to see progress here. /cc @rrelyea |
nkolev92
added
Priority:3
dotnet-policy-service
bot
added
the
missing-required-type
dotnet-policy-service
bot
removed
the
missing-required-type
|
While this is quite an old issue, I think it's more important now because of the change done in security checks to consider vulnerabilities from transitive packages, which causes false positives like #13622. @nkolev92 Should we expect this to be fixed before .NET 9 becomes stable? Otherwise, how should we deal with false positives? |
|
Supplied by platform will not make the 9.0.100 SDK, but it is among our highest priorities, so it is getting actively worked on currently. As per our recent blog post: https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/ there are a few options, such as:
|
This PR does 3 things. 1. Adds `TargetFramework` to NuGet package references. This can be useful when querying component data to understand if components are used in a place where a vulnerability applies. 2. Adds _framework package_ handling. The .NET SDK will do [conflict resolution](https://github.com/dotnet/sdk/tree/main/src/Tasks/Common/ConflictResolution) and drop assets from packages that overlap with the framework. NuGet is planning to do the same NuGet/Home#7344 but until then, it's beneficial to have component detection duplicate some of this logic. When a package is identified as overlapping with the framework we'll treat it as a Development Dependency so that it might be auto-dismissed. - .NETFramework projects do not get this - .NETFramework does not participate in conflict resolution by default. Even when enabled framework assemblies can be bypassed using bindingRedirects, or avoiding references to them. Due this fragility it's not safe to apply framework package rules to .NETFramework. - packages.config usage is also excluded since it precludes SDK conflict resolution (and is also only used on .NETFramework projects). 3. Recognizes `ExcludeAssets="Runtime"` usage as a Development Dependencies, also any packages which don't contribute to "runtime" will be developement dependencies. I reused _Development Dependency_ rather than plumbing a new concept. I only mapped data for the `Microsoft.NETCore.App` - the default shared framework. We could consider doing the same for `Microsoft.ASPNETCore.App` and `Microsoft.WindowsDesktop.App` but we'd need to plumb the reference information out of the assets file - currently that's not read and I'm not aware of a supported NuGet API for reading it (though it is present under `project/frameworks/<framework>/frameworkReferences/<name>` .NET Core 1.x has no data since it was packages itself. I have a fallback for future frameworks to read the data from the targeting packs.
…1285) * Add experimental NuGet detector for framework and dev dependencies This PR does 3 things. 1. Adds `TargetFramework` to NuGet package references. This can be useful when querying component data to understand if components are used in a place where a vulnerability applies. 2. Adds _framework package_ handling. The .NET SDK will do [conflict resolution](https://github.com/dotnet/sdk/tree/main/src/Tasks/Common/ConflictResolution) and drop assets from packages that overlap with the framework. NuGet is planning to do the same NuGet/Home#7344 but until then, it's beneficial to have component detection duplicate some of this logic. When a package is identified as overlapping with the framework we'll treat it as a Development Dependency so that it might be auto-dismissed. - .NETFramework projects do not get this - .NETFramework does not participate in conflict resolution by default. Even when enabled framework assemblies can be bypassed using bindingRedirects, or avoiding references to them. Due this fragility it's not safe to apply framework package rules to .NETFramework. - packages.config usage is also excluded since it precludes SDK conflict resolution (and is also only used on .NETFramework projects). 3. Recognizes `ExcludeAssets="Runtime"` usage as a Development Dependencies, also any packages which don't contribute to "runtime" will be developement dependencies. I reused _Development Dependency_ rather than plumbing a new concept. I only mapped data for the `Microsoft.NETCore.App` - the default shared framework. We could consider doing the same for `Microsoft.ASPNETCore.App` and `Microsoft.WindowsDesktop.App` but we'd need to plumb the reference information out of the assets file - currently that's not read and I'm not aware of a supported NuGet API for reading it (though it is present under `project/frameworks/<framework>/frameworkReferences/<name>` .NET Core 1.x has no data since it was packages itself. I have a fallback for future frameworks to read the data from the targeting packs. * Address feedback
…#470) * Update NuGet dependencies to fix vulnerability warn * Update IsoCreator packages * Supress NuGet false positives with .NET 9.100 NuGet/Home#7344
|
👏 |
With .NET Core 3.0, we will be using targeting packs to deliver reference assemblies for the framework. These targeting packs will not be represented as NuGet packages in the package graph in the way that Microsoft.NETCore.App, Microsoft.AspNetCore.App, and NETStandard.Library currently are.
When a .NET Core 3 project depends on a package that has a dependency on one of these older "platform" packages, we want that platform package and its dependencies to be ignored in the NuGet graph, as those APIs are supplied by the platform via other mechanisms (targeting packs at build time and runtime packs for self-contained deployments).
We've thought of two possible ways to exclude the platform packages and dependencies from the graph. This issue is for one of them. The other one is #7343
To exclude these packages, we could pass an additional list of packages to the restore operation that should be ignored in the graph walk. We might call these "Supplied by Platform" packages. When walking the graph, if the restore operation encountered a dependency on any of these package (with a version less than or equal to the version marked as supplied by the platform), then it would ignore that dependency (and would not walk its dependencies further).
Spec: https://github.com/NuGet/Home/blob/dev/accepted/2024/prune-package-reference.md
Project-System changes: dotnet/project-system#9610
The text was updated successfully, but these errors were encountered: