build: pin patched System.Security.Cryptography.* / SignalR to clear fresh-restore NuGet audit

Claude-Session: https://claude.ai/code/session_01Ub9hGmYLQvn9XETzw7CMsT
This commit is contained in:
Joseph Doherty
2026-10-22 10:38:07 -04:00
parent 7513ce5144
commit a01f5e6705
4 changed files with 46 additions and 1 deletions
+32 -1
View File
@@ -40,6 +40,17 @@
<PackageVersion Include="Microsoft.AspNetCore.DataProtection.EntityFrameworkCore" Version="10.0.7" />
<PackageVersion Include="Microsoft.AspNetCore.Mvc.Testing" Version="10.0.0" />
<PackageVersion Include="Microsoft.AspNetCore.SignalR.Client" Version="10.0.0" />
<!--
Surgical transitive pin #4. GHSA-334f-vvp4-7g6p (CVE-2026-70159, NU1903 high) flags
Microsoft.AspNetCore.SignalR.Common 10.0.0..10.0.12, which SignalR.Client 10.0.0 pulls in via
SignalR.Client.Core. 10.0.13 is the first fixed version, pinned by direct PackageReference in
AdminUI (the one project that references SignalR.Client). Bumping SignalR.Client itself to
10.0.13 was tried and rejected: SignalR.Client.Core 10.0.13 floors Microsoft.Extensions.Logging /
DependencyInjection at 10.0.13, which the AdminUI shared framework absorbs but non-Web consumers
downstream (OpcUaServer.IntegrationTests, which references Logging.Abstractions 10.0.7 directly)
do not, producing an NU1605 downgrade.
-->
<PackageVersion Include="Microsoft.AspNetCore.SignalR.Common" Version="10.0.13" />
<PackageVersion Include="Microsoft.AspNetCore.SignalR.Core" Version="1.2.0" />
<PackageVersion Include="Microsoft.AspNetCore.TestHost" Version="10.0.7" />
<!--
@@ -149,8 +160,28 @@
Microsoft.Extensions.* and, through the EFCore adapter, Microsoft.EntityFrameworkCore at
10.0.10, forcing a family-wide servicing bump (NU1605 downgrade cascade) that deserves its own
reviewed change.
2026-10-22: raised 10.0.10 -> 10.0.13. Three more NU1903 advisories (GHSA-7hqp-7c5m-4vq6,
GHSA-c399-9853-6jmj, GHSA-r955-8q5j-3h83; vulnerable <= 10.0.12) landed against 10.0.10, again
red only on a fresh restore (~67 projects). 10.0.13 is the first fixed version. Same pin site,
same reasoning against the DataProtection parent bump.
-->
<PackageVersion Include="System.Security.Cryptography.Xml" Version="10.0.10" />
<PackageVersion Include="System.Security.Cryptography.Xml" Version="10.0.13" />
<!--
Surgical transitive pin #3. GHSA-846f-f764-76mx (NU1903 high) + GHSA-2fmv-rv2c-59x7 (NU1902
moderate) flag System.Security.Cryptography.Pkcs <= 10.0.12 and 9.0.0..9.0.20. Two chains bring
it in, both entering at Core.Configuration:
- System.Security.Cryptography.Xml 10.0.x -> Pkcs 10.0.x (same version as Xml), and
- Microsoft.EntityFrameworkCore.SqlServer 10.0.7 -> Microsoft.Data.SqlClient 6.1.1 -> Pkcs 9.0.4.
In Web-SDK consumers (AdminUI, ControlPlane, Host, Security, ...) the ASP.NET Core shared
framework prunes the Xml chain, so the SqlClient 9.0.4 floor is what resolves there (~9
projects); everywhere else the Xml chain's 10.0.10 won (~67 projects). Raising the Xml pin alone
only fixes the second group, so Pkcs is pinned explicitly at 10.0.13 (first fixed 10.x) by a
direct PackageReference in Core.Configuration. Its net10.0 dependency group is empty, so the pin
floors nothing else. Bumping Microsoft.Data.SqlClient / EFCore.SqlServer instead would be the
family-wide servicing bump the Xml note above declines.
-->
<PackageVersion Include="System.Security.Cryptography.Pkcs" Version="10.0.13" />
<PackageVersion Include="System.CommandLine" Version="2.0.5" />
<PackageVersion Include="System.Data.SqlClient" Version="4.9.0" />
<PackageVersion Include="System.IdentityModel.Tokens.Jwt" Version="8.11.0" />
@@ -28,6 +28,10 @@
Directory.Packages.props. This is the one project where the DataProtection chain
enters the repo; every other consumer reaches it through a ProjectReference here. -->
<PackageReference Include="System.Security.Cryptography.Xml"/>
<!-- Surgical transitive pin — see the System.Security.Cryptography.Pkcs block in
Directory.Packages.props. Microsoft.Data.SqlClient (via EFCore.SqlServer) enters here
too and pulls a vulnerable Pkcs 9.0.4 wherever the shared framework prunes the Xml chain. -->
<PackageReference Include="System.Security.Cryptography.Pkcs"/>
<PackageReference Include="Microsoft.Extensions.Configuration.Abstractions"/>
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions"/>
<PackageReference Include="Polly.Core"/>
@@ -26,6 +26,10 @@
provider's DbProviderFactory (NpgsqlFactory / OracleClientFactory); both packages are fully
managed ADO.NET drivers, so adding them costs no native client install anywhere. -->
<PackageReference Include="Microsoft.Data.SqlClient" />
<!-- Surgical transitive pin — see the System.Security.Cryptography.Pkcs block in
Directory.Packages.props. SqlClient 6.1.1 pulls a vulnerable Pkcs 9.0.4; this is the
second place the SqlClient chain enters the repo (Core.Configuration is the first). -->
<PackageReference Include="System.Security.Cryptography.Pkcs" />
<PackageReference Include="Npgsql" />
<PackageReference Include="Oracle.ManagedDataAccess.Core" />
</ItemGroup>
@@ -9,6 +9,12 @@
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App"/>
<PackageReference Include="Microsoft.AspNetCore.SignalR.Client"/>
<!-- Surgical transitive pin — see the Microsoft.AspNetCore.SignalR.Common block in
Directory.Packages.props (GHSA-334f-vvp4-7g6p on SignalR.Common 10.0.0). Inside AdminUI
the shared framework already supplies it (hence NU1510), but the PackageReference flows
to the non-Web consumers (Host.Tests, AdminUI.Tests, OpcUaServer.IntegrationTests) where
SignalR.Client 10.0.0 would otherwise resolve the vulnerable 10.0.0. -->
<PackageReference Include="Microsoft.AspNetCore.SignalR.Common" NoWarn="NU1510"/>
<PackageReference Include="ZB.MOM.WW.Theme"/>
<PackageReference Include="ZB.MOM.WW.Secrets.Ui"/>
</ItemGroup>