Support replacing a package from my graph

[aortiz-msft]

NuGet Product(s) Involved

dotnet.exe

The Elevator Pitch

Say my application is using a vulnerable package, and the author is taking too long to patch. Would be great if I could replace that package in my graph easily with a package I provide that has the patch. So, with CPM, have a list that says, whenever you see PackageA, change it to PackageB.

Additional Context and Details

No response

[jebriede]

@aortiz-msft thanks for filing this! It sounds like there are two variations of this scenario. If the package author has shipped a patched version under the same package ID, the recommended way to handle this would be to promote the transitively referenced package to a top-level package at the patched version by installing it explicitly using the NuGet Package Manager or the dotnet add package command and specifying the package and version, or by manually editing your csproj or Directory.Packages.props if using CPM.

If instead you want to redirect to a different package altogether, like your own repackaged build that carries the patch, that isn't something NuGet supports today, since the rest of your graph still depends on the original package's identity and the replacement wouldn't satisfy those references. That second variation is a more complex feature ask, and it comes with some design tradeoffs around auditability, lock files, and the other implications of rewriting package identity during restore.

Would the promotion approach fully support your scenario, or are you specifically considering a package-to-package replacement? And if it's the latter, do you have suggestions on how you'd want this to work?

[aortiz-msft]

If instead you want to redirect to a different package altogether, like your own repackaged build that carries the patch, that isn't something NuGet supports today, since the rest of your graph still depends on the original package's identity and the replacement wouldn't satisfy those references. That second variation is a more complex feature ask, and it comes with some design tradeoffs around auditability, lock files, and the other implications of rewriting package identity during restore.

This is exactly the idea to be tracked by this issue.