Closed mus65 closed 3 weeks ago
@dotnet-policy-service agree
/azp run
I don't agree with the changes, as this is added purposely. What false positives are you concerned about?
This dependency is simply not necessary since the .NET runtime itself already contains System.Text.Json . This causes false positives in NuGet Audit because if a library like Microsoft.Data.SqlClient e.g. depends on the vulnerable System.Text.Json 8.0.4, but I'm actually using the latest .NET runtime which contains the fixed 8.0.5, the SDK will use the latest version. Meaning I'm not actually affected by the vulnerability, but NuGet Audit will still claim that I am.
NuGet is actually working on fixing this, so it considers the runtime dependencies (see Supplied by Platform ). But even when they fix this, not having this unnecessary dependency in the first place is imho the better option.
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 75.94%. Comparing base (
39c4604
) to head (1569786
). Report is 4 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Based on comment https://github.com/NuGet/Home/issues/7344#issuecomment-2311075251, I believe Supplied by Platform is not yet available in .NET 8 or 9. Can you confirm my understanding?
@cheenamalhotra that is correct, but only affects potential nuget audit warnings. Adding this as an explicit reference with .NET 8 is wrong.
I hope this can be backported unless v6 is coming very soon and in ef SQL by default. Every time a system.text.json vuln comes up we're having to update it explicitly just because of SQL client lib, other Ms libs don't show the same explicit dependency
@mungojam Why backported? This was introduced in 6.x
Partial revert of #2921 . System.Text.Json is part of the framework on modern .NET, so this dependency is unnecessary and wil just cause false positives in NuGet audit.
It will still be needed for .net framework consumers so you might need a conditional package reference instead
@mungojam
It will still be needed for .net framework consumers so you might need a conditional package reference instead
The .NET Framework reference is still there, it was already conditional because .NET Framework/.NET have different csproj files.
@mungojam Why backported? This was introduced in 6.x
@ErikEJ my mistake, it comes in with sub-dependencies in v5. Hopefully these don't bring it in in v6:
Thanks to dotnet nuget why ./ System.Text.Json
, what a great addition :)
Partial revert of #2921 . System.Text.Json is part of the framework on modern .NET, so this dependency is unnecessary and wil just cause false positives in NuGet audit.