Pin System.Security.Cryptography.Xml to 8.0.3 in tests#2232
Conversation
Closes high-severity CVE-2026-33116 and CVE-2026-26171 pulled in transitively via System.ServiceModel.Primitives 8.1.0 on the net8.0/9.0/10.0 test legs.
Is there actually a need for the .NET Framework builds to use the System.ServiceModel NuGet package at all, or can they just use the in-box System.ServiceModel version? (Its built in to Framework, but not Core). |
That is what i meant. I though that that was the version of the net framework assemblies. |
|
I mean that there might not be any purpose in referencing the System.ServiceModel.Http NuGet packages in the net462 or net48 TFMs - e.g. maybe could just be And then the whole thing would be simpler? |
|
I agree How about this? |
Collapse per-TFM ItemGroups into shared .NETFramework / .NETCoreApp groups, and switch .NET Framework targets to the in-box System.ServiceModel reference instead of out-of-band packages. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
0d69d7c to
74c511d
Compare
|
Thank you for providing detailed MR desc. It helps a lot when sighting/assessing new releases and upgrade paths and necessity. |
Closes #2233.
Summary
Pins
System.Security.Cryptography.Xmlto8.0.3as a directPackageReferenceinSerilog.Testsfor thenet8.0,net9.0, andnet10.0legs.The vulnerable
8.0.2is brought in transitively viaSystem.ServiceModel.Primitives 8.1.0(which itself is brought in bySystem.ServiceModel.Http 8.1.0). On the 8.x line,8.0.3is the first patched version per the Microsoft advisories.Currently, a fresh
dotnet restoreagainstdevfails withNU1903for two high-severity CVEs:Both were published 2026-04-14, after the last green CI run on
dev.Why pin instead of bump
There is no 9.x line of
System.ServiceModel.*; Microsoft jumped from 8.x to 10.x, andSystem.ServiceModel.Primitives 8.1.2(latest 8.x) still pins the vulnerable8.0.2. Bumping to 10.x changes the dep graph more broadly. Pinning the transitive directly is the minimal, surgical fix that keeps the rest of the graph intact.The net462/net48 legs are unaffected: on .NET Framework, assemblies of System.ServiceModel are provided by the framework itself, so they don't pull System.Security.Cryptography.Xml 8.0.2 transitively. No pin is needed there.
Test plan
dotnet restoreclean (noNU1903)dotnet build -c Releaseclean — 0 warnings, 0 errorsdotnet test test/Serilog.Tests— 815/815 passing onnet8.0,net9.0,net10.0Serilog.ApprovalTestspasses (no public-API drift)windows-latestcovers thenet48/net462legs