Repository navigation
After creating a Worker service project, "System.text.json" 8.0.0 was referenced and identified as a vulnerable package #105120
Description
Activity
@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.
The
System.Text.Jsonv8.0.0dependency is coming from the following dependency graph:
@ericstj @eiriktsarpalis @ViktorHofer - are we planning on updating
Microsoft.Extensions.Hostingto uplift theSystem.Text.Jsondependency 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 everyWorkerapp will have this vulnerability warning now. I am able to repro it by just creating aWorker serviceproject in VS. This makes me think this issue should be transfered to dotnet/runtime.Thoughts?
I would say this is a duplicate of #104669. The current policy is that we don't update because of transitive dependencies being vulnerable.
Reacted by Eric StJohnReacted by Jozef Izso and KeterSCPReacted by Juliano Leal GoncalvesCorrect, it will ship with updated dependencies if it has a reason to ship.
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 workeris now setting off these kinds of vulnerability warnings due to a transitive dependency on the STJ8.0.0nuget package. Options to address this that I can see are:- We do nothing and tell customers they are responsible for "fixing up" our templates so they don't get warnings.
- We teach the vulnerability warnings about package conflict resolution, so they don't warn about the
8.0.0nuget package being referenced transitively when the real System.Text.Json assembly will be loaded from the shared framework. - We are super stringent about TFM dependencies - in this case
Microsoft.Extensions.Configuration.JsonandMicrosoft.Extensions.Logging.Consoleshouldn't have a nuget dependency onSystem.Text.Jsonfor thenet8.0TFM. It should come from the TFMnet8.0. - We update a targeted set of packages that are used directly in applications - in this case
Microsoft.Extensions.Hostingv8.0.1gets shipped that "lifts up" the System.Text.Json version to a non-vulnerable one. That way I just need to reference the latestMicrosoft.Extensions.Hostingversion in my worker app, and I no longer get security alerts. - We update our templates (ex.
workerandaspire) 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.
Reacted by bejaxTagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.- changed the title
[-][WebToolsE2E] [Aspire] After creating an aspire project, "System.text.json" 8.0.0 was referenced and identified as a vulnerable package[/-][+]After creating a Worker service project, "System.text.json" 8.0.0 was referenced and identified as a vulnerable package[/+]on Jul 18, 2024 Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.The proposed fix from @eerhardt is:
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.
Thoughts @ericstj @eiriktsarpalis?
Reacted by bejaxI think that's reasonable to avoid dependencies when they're present in the framework. I see that as a nice improvement to avoid package downloads.
Reacted by bejaxSo there's a complication here. If a package needs a reference for
NETStandard2.0we may not be able to remove the package reference for older .NET versions. Consider the following package shape:A (netstandard2.0) -> B (package - 9.0.0.0)
A (net8.0) -> B (framework - 8.0.0.0 | package - 9.0.0.0)
A (net9.0) -> B (framework - 9.0.0.0)We can't remove the package reference for net8.0 because that would cause a ref-def mismatch for folks compiling on netstandard2.0 then running on net8.0 - since net8.0 only contains the 8.0.0.0 version. Even if we're OK using the API that's in 8.0 when compiling for it, we must deliver the 9.0 assembly since that's what we expose on netstandard2.0.
We can still remove the package reference for the current framework, but not past ones in this case.
We only made this change for
net9.0in RC1. If you are using targetingnet9.0and an RC1 build you should see the fix.We only made this change for
net9.0in RC1. If you are using targetingnet9.0and an RC1 build you should see the fix.Thanks! With 9.0 RC1, the dependency has been removed. For 8.0 templates in VS 17.11 and below, the package warning is only shown when checking for vulnerable packages from the nuget package manager. For 8.0 templates in VS 17.12 (where the default SDK is 9.0), we're tracking an issue https://github.com/dotnet/AspNetCore-ManualTests/issues/3047
Verify that this issue has been fixed in SDK 8.0.403.
I have noticed that updating a reference to System.Data.OleDb from v8.0.0 to v8.0.1 in a WinForms project will now cause additional DLLs to be copied to the output folder, namely System.Configuration.ConfigurationManager.dll and a few others. (The new OleDb version is a result of the backport https://github.com/dotnet/runtime/pull/107161/files#diff-30298982b02597cb3012558d2f74db967ea32ef46132610ba0fd030fe62eb727 if I understand correctly.)
Failure to deploy these extra DLLs with your app may result in assembly load errors at runtime (possibly only when running on a pre-8.0.10 .NET 8 runtime).
Was this change intentional?
- locked and limited conversation to collaborators
on Nov 14, 2024
Repro steps
dotnet new workerExpected 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
REPRO STEPS
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:
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.