After creating a Worker service project, "System.text.json" 8.0.0 was referenced and identified as a vulnerable package

[v-bennettyue]

Repro steps

1. dotnet new worker
2. Open project in Visual Studio
3. Right-client project > Manage NuGet Packages

Expected results

The project shouldn't have vulnerability warnings

Actual results

Check 'Show only vulnerable' checkbox, then you can see that the warning is because the following packages have a dependency on System.text.json 8.0.0, which has been detected as the vulnerable package

Original issue

INSTALL STEPS

1. Clean machine: Win11 x64 23h2 ENU
2. Install Dev17.10.4 (Include Aspire 8.0.0) latest release build
   • Web workload

REPRO STEPS

1. File > New project > .NET Aspire App Host > .NET 8.0 > Create
2. Right-check project > Manage NuGet Packages

ACTUAL
Check 'Show only vulnerable' checkbox, then you can see that the warning is because the following packages have a dependency on System.text.json 8.0.0, which has been detected as the vulnerable package
Aspire.Hosting.AppHost "Version=" 8.0.0

NOTE:

1. This issue can be repro in any aspire project or in a project with aspire
   This issue also repro on Dev17.10 + Aspire 8.0.2/8.1 and Dev17.11 + Aspire 8.0.2/8.1

EXPECTED
The packages should be updated to depend on a newer version of System.text.json that is not vulnerable.

[balachir]

@mitchdenny is this a known issue? Note that this also reproduces using Aspire 8.0, so this may not be a blocking issue for Aspire 8.1. But if it's a straight-forward dependency update, perhaps we should go ahead and get it done.

[eerhardt]

The System.Text.Json v8.0.0 dependency is coming from the following dependency graph:

@ericstj @eiriktsarpalis @ViktorHofer - are we planning on updating Microsoft.Extensions.Hosting to uplift the System.Text.Json dependency to a non-vulnerable version? I know in this case the NuGet package isn't going to be used (since the System.Text.Json used will come from the shared framework). But I would guess every Worker app will have this vulnerability warning now. I am able to repro it by just creating a Worker service project in VS. This makes me think this issue should be transfered to dotnet/runtime.

Thoughts?

[eiriktsarpalis]

I would say this is a duplicate of #104669. The current policy is that we don't update because of transitive dependencies being vulnerable.

[ericstj]

Correct, it will ship with updated dependencies if it has a reason to ship.

[eerhardt]

The current policy is that we don't update because of transitive dependencies being vulnerable.

I agree with this policy from a library perspective - so we don't have an explosion of new versions of all libraries in the world that depend on System.Text.Json.

However, from an application perspective we are causing an issue for any application using our templates. dotnet new worker is now setting off these kinds of vulnerability warnings due to a transitive dependency on the STJ 8.0.0 nuget package. Options to address this that I can see are:

1. We do nothing and tell customers they are responsible for "fixing up" our templates so they don't get warnings.
2. We teach the vulnerability warnings about package conflict resolution, so they don't warn about the 8.0.0 nuget package being referenced transitively when the real System.Text.Json assembly will be loaded from the shared framework.
3. We are super stringent about TFM dependencies - in this case Microsoft.Extensions.Configuration.Json and Microsoft.Extensions.Logging.Console shouldn't have a nuget dependency on System.Text.Json for the net8.0 TFM. It should come from the TFM net8.0.
4. We update a targeted set of packages that are used directly in applications - in this case Microsoft.Extensions.Hosting v8.0.1 gets shipped that "lifts up" the System.Text.Json version to a non-vulnerable one. That way I just need to reference the latest Microsoft.Extensions.Hosting version in my worker app, and I no longer get security alerts.
5. We update our templates (ex. worker and aspire) to manually "lift up" the dependency to a non-vulnerable version.

Of these options, I think (3) might be the best. I'm not sure if we could make that kind of change in a servicing release, but we should think about that policy going forward so we don't get into these kinds of situations in the future.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.