fix(security): bump System.Security.Cryptography.Xml to 8.0.4 (5 HIGH advisories) - #24
Conversation
8.0.3 is now affected by five published high-severity advisories, all of which are first patched in 8.0.4: GHSA-23rf-6693-g89p CVE-2026-50648 .NET Denial of Service GHSA-8q5v-6pqq-x66h CVE-2026-50525 .NET Denial of Service GHSA-cvvh-rhrc-wg4q CVE-2026-47302 .NET Denial of Service GHSA-g8r8-53c2-pm3f CVE-2026-47304 .NET Security Feature Bypass GHSA-mmjf-rqrv-855v CVE-2026-50527 .NET Denial of Service This is why CI has failed on every main commit since 2026-06-04: NuGetAudit raises NU1903 as an error during restore, so build-and-test never gets past the restore step. Releases 1.0.0 and 1.0.1 were both cut from that red build, and PostQuantum.DataProtection 1.0.1 on nuget.org declares a direct dependency on the vulnerable 8.0.3 -- inherited by .Aws, .AzureKeyVault, .Cli, .Fips, .OpenTelemetry, .Redis and .Testing. 8.0.4 stays inside the 8.0.x line and ships lib/net8.0, so this preserves the net8.0;net9.0;net10.0 target set. Dependabot's alternative (PR #21, bumping to 10.0.9) would both drop net8.0/net9.0 support and remain vulnerable, since the 10.x line is only patched in 10.0.10. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
With the NU1903 restore block lifted, CI reaches the test step on macOS for
the first time since 2026-06-04 -- and 63 tests fail there with:
System.PlatformNotSupportedException :
System.Security.Cryptography.MLKem is not available on this platform.
macOS has no .NET 10 ML-KEM backend, so any test performing a real
encapsulation cannot run there. This is pre-existing and unrelated to the
System.Security.Cryptography.Xml bump; restore simply never got far enough
to reveal it. Windows passes the full suite.
Adds PqcFactAttribute / PqcTheoryAttribute, which set Skip when
MLKem.IsSupported is false, and applies them to exactly the 56 affected test
methods across 18 classes. The remaining 43 tests still run on macOS, so
platform coverage of the non-crypto paths is preserved.
This mirrors the PqcFactAttribute already used in postquantum-aspnetcore:
a test that cannot run its crypto skips with a reason, never silently passes.
The Linux and Windows legs continue to execute the full suite, so a real
regression cannot hide behind these skips.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Added a second commit: With the Adds |
With NU1903 cleared, CI reaches the test step on Linux for the first time since 2026-06-04 -- and reports: Passed: 45 Skipped: 56 MLKem.IsSupported is false on the ubuntu runner: the stock OpenSSL there predates 3.5, so the .NET 10 ML-KEM backend is unavailable. The PqcFact guard added in the previous commit therefore skips the entire ML-KEM suite on Linux rather than only on macOS, coverage collapses below the 85% line gate, and the gate fails. Skipping was the wrong outcome. For a post-quantum library a silently-skipped crypto suite is indistinguishable from a passing one -- the sibling repository postquantum-aspnetcore carries a comment noting this exact failure mode once hid a broken Linux PQ lane. Two changes: 1. Install OpenSSL 3.5+ from conda-forge on the Linux leg and point LD_LIBRARY_PATH at it for both the test and coverage runs, so the ML-KEM tests actually execute there. A probe step prints MLKem.IsSupported before the suite runs, so if this ever regresses the log answers the first question directly. 2. Add a zero-skip gate on the Linux and Windows lanes. Both have the primitive available, so any skip there means the PQ paths went unproven and the job should fail. macOS is exempt -- it has no ML-KEM backend at all, which is what PqcFact legitimately covers. This mirrors the linux-pq-required lane already in postquantum-aspnetcore. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The gate matched the older one-line VSTest summary ("Passed! - Failed: 0,
Skipped: 0, ..."), but this SDK prints an indented per-project form:
Passed: 108
and omits the Skipped line entirely when nothing skipped. Both lanes therefore
failed with "Could not locate a dotnet test summary line" even though the run
was clean.
The substantive change in the previous commit is confirmed working -- the Linux
lane now reports:
MLKem.IsSupported = True
Passed: 108
against 45 passed / 56 skipped before it, so the conda OpenSSL 3.5+ makes the
ML-KEM suite actually execute on Linux.
Now sums Passed and Skipped across every summary line, handles both shapes, and
additionally fails when no passing tests are found at all -- an empty or crashed
run must not slip through a gate whose only job is to prove the suite ran.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
With set -euo pipefail, `skipped=$(grep -oE 'Skipped:...' ...)` aborts the step when the log contains no "Skipped:" line -- which is exactly the clean case this gate exists to confirm. grep exits 1, pipefail propagates it, set -e kills the step, and nothing is printed, so both lanes failed with no diagnostic output despite 108 passing tests and zero skips. Guards both counts with `|| true`. The explicit passed==0 check still catches a genuinely empty or crashed run, so the gate keeps its purpose. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bumps all eight packable projects 1.0.1 -> 1.0.2, records the release in the changelog, and advances the README status line. Patch rather than minor: no wire-format change and no public API change. Every 1.0.1 envelope decodes identically, so this is a drop-in over 1.0.1. The release exists to ship the System.Security.Cryptography.Xml 8.0.3 -> 8.0.4 fix from #24. 1.0.1 declares the vulnerable version as a direct dependency of the core package, and .Aws, .AzureKeyVault, .Cli, .Fips, .OpenTelemetry, .Redis and .Testing all depend on the core -- so all eight published packages currently resolve a library carrying five HIGH-severity advisories. Upgrading is recommended for every consumer. Note this repository has no release automation: there is no release.yml and nothing in CI pushes to NuGet, so v1.0.0 and v1.0.1 were published by hand. This PR prepares the release; packing and pushing remain a manual step. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
What
Bumps
System.Security.Cryptography.Xmlfrom 8.0.3 → 8.0.4 insrc/PostQuantum.DataProtectionand the test project, and refreshes the explaining comment.Why
8.0.3 is affected by five published HIGH-severity advisories, all first patched in 8.0.4:
The existing pin was correct when written — 8.0.3 patched the earlier pair (GHSA-37gx-xxp4-5rgx, GHSA-w3x6-4m5h-cxqf). These five landed after.
This is the cause of the long-standing red CI
NuGetAuditraisesNU1903as an error during restore, sobuild-and-testfails before it compiles anything:CI has failed on every main commit since 2026-06-04 — including the commits tagged
Release 1.0.0andRelease 1.0.1.It reached the published packages
PostQuantum.DataProtection 1.0.1on nuget.org declares a direct dependency on the vulnerable 8.0.3. Seven sibling packages depend on it and inherit the exposure:.Aws,.AzureKeyVault,.Cli,.Fips,.OpenTelemetry,.Redis,.Testing. A patch release is warranted once this is green.Why 8.0.4 and not 10.0.9
Dependabot proposed 10.0.9 in #21. That option is worse on both axes:
Microsoft.AspNetCore.DataProtection10.0.9 ships onlynet462/netstandard2.0/net10.0dependency groups, dropping thenet8.0/net9.0targets this project multi-targets.8.0.4 stays in the 8.0.x line and ships
lib/net8.0, sonet8.0;net9.0;net10.0is preserved. #21 and #18 should stay closed or be reworked.Verification
Expect
build-and-testto pass restore for the first time since June. Note the account's Actions queue is currently backlogged, so results may be slow.🤖 Generated with Claude Code