Repository navigation
Repair stale emSign trust locks in active Server parity fixtures #703
Description
Problem
Current main 3f448d3099848d6d8ec5971432bd8b60f26dfec3 still has five active Server parity-fixture locks resolving the trust-store versions affected by the eMudhra/emSign incident:
scripts/conformance/server-parity/corrected-markers/rust/Cargo.lockscripts/conformance/server-parity/legacy-marker-aliases/rust/Cargo.lockscripts/conformance/server-parity/published-sdk-patch/rust/Cargo.lockscripts/conformance/server-parity/query-authority/rust/Cargo.lockscripts/conformance/server-parity/sdk-directions/rust/Cargo.lock
Each resolves rustls-webpki 0.103.15 and webpki-roots 1.0.9, below the fixed floors 0.103.16 and 1.0.10 from RUSTSEC-2026-0381 / RUSTSEC-2026-0382.
These are active executable inputs, not archived evidence. The corresponding adapter paths copy each lock into parity evidence and run cargo build --locked; all five are exercised from .github/workflows/server-parity.yml or its invoked scripts. The separate historical lock under docs/evidence/server-237-20260929-published-rust212/ remains immutable and is not part of this correction.
PR #671 updated the native Server and capacity-binding locks, but its reviewed two-lock scope did not include these five parity consumers. The same class of active-fixture omission was subsequently corrected in SDK Rust #137 / PR #138.
This is preventive supply-chain remediation. It is not evidence that a build was intercepted or that a published runtime/customer was compromised.
Required correction
- Refresh only the five active locks above to
rustls-webpki 0.103.16andwebpki-roots 1.0.10, preserving their deliberately pinned SDK versions and fixture behavior. - Add a fail-closed repository contract that inventories active
Cargo.lockfiles outside immutable evidence and rejects either affected predecessor version, so another live fixture cannot be omitted silently. - Prove every affected documented
cargo build --lockedpath with its normal pinned Rust 1.86 toolchain and no network during compilation after a separately trusted fetch. - Run the normal Server parity/source qualification on the exact corrected head and retain the existing historical evidence lock byte-for-byte.
This touches Rust/shared parity fixtures reserved to the Rust Server owner. Security is recording the exact finding and acceptance boundary, not starting a competing fixture edit.
Refs #671, #673, GHSA-6q48-6c7w-9gw2.
Activity
rmcdaniel commentedon Oct 23, 2026
Security scope verification: parsed every current-main Cargo.lock across Server, SDK Rust, SDK PHP, Workflow and Sample App. Every active lock outside Server is at rustls-webpki 0.103.16 / webpki-roots 1.0.10. Within Server, native, capacity and ActivityLeaseConsumers are fixed; exactly the five issue-body parity locks remain affected. The only other old pair is docs/evidence/server-237-20260929-published-rust212/Cargo.lock, which is immutable historical evidence and must remain unchanged. This makes the five-path correction complete rather than a sample-based inventory.
Move the five parity fixture locks to the fixed TLS trust crates
rmcdaniel commentedon Oct 23, 2026
Fixed in #673 at
802f843a93a801040f0685e7f37f66686510173f(commit802f843a9). The issue closes when #673 merges.rustls-webpki0.103.15→0.103.16 andwebpki-roots1.0.9→1.0.10 change. The checksums match those already inrust/Cargo.lock. The SDK pins and fixture behavior are unchanged.tests/Unit/Support/cargo_lock_trust_test.py. It runs in the PHPUnit feature workflow and walks everyCargo.lockin the tree. Each one outside the listed immutable evidence must resolve at least those versions, and a failure names every stale lock. The evidence lock must keep its recorded sha256, and the eight known locks must be found. Against the previous locks it fails and names all five.cargo build --locked --offlineunder--network noneafter a separatecargo fetch --locked. All five succeeded, with no download during the builds.docs/evidence/server-237-20260929-published-rust212/is byte-for-byte unchanged.Record the corrected-markers adapter's new lock digest
rmcdaniel commentedon Oct 23, 2026
Security review correction: the five current locks and corrected-markers digest are correct, but the new fail-closed inventory acceptance is not complete yet. The regex parser misses a stale package in a future valid Cargo.lock when another TOML key separates
nameandversion, and the version parser treats a prerelease at the numeric floor as the final fixed release. Exact counterexamples and requestedtomllib/SemVer controls are recorded on #673 at #673 (comment). Keep #703 open until those tests pass on the final combined #673 head; immutable evidence remains unchanged.