[QuantumExplorer]

Basic explanation

What this does: Updates three small Rust libraries that decide which HTTPS/TLS certificates Platform's Rust code trusts. webpki-roots and webpki-root-certs are the built-in lists of trusted certificate authorities; rustls-webpki checks a server's certificate chain against that list. The new versions stop trusting certificates issued by a set of emSign (eMudhra) authorities whose private keys are now publicly known. Only Cargo.lock changes.

Value: The nightly "Security: Rust Crates" audit on v5.0-dev goes from 7 vulnerabilities to 4, so 5.0.0 does not ship with these TLS advisories. The fix reaches everything that connects to DAPI or other servers over TLS from Rust: rs-dapi, the Rust SDK, and the FFI, mobile and wasm SDKs built on it.

Risks: Low. These are patch releases on the same semver lines, with no new dependencies and no API changes. No consensus code is touched (block execution does not use TLS). The one visible behaviour change is intended: a server whose certificate chains to one of the removed roots (listed below) now fails the TLS handshake. Certificates that dashmate obtains from ZeroSSL or Let's Encrypt do not chain to those roots; only a node using the file provider with a certificate bought from one of those authorities would be affected.

Issue being fixed or feature implemented

The nightly cargo audit job (.github/workflows/security-audit-rust.yml) went red again on v5.0-dev after #5499, because new advisories were published between 2026-10-19 and 2026-10-23:

Advisory	Crate	Locked	Fixed in
RUSTSEC-2026-0382	rustls-webpki	0.103.15	0.103.16
RUSTSEC-2026-0381	webpki-roots	1.0.7	1.0.10
RUSTSEC-2026-0383	webpki-root-certs	1.0.7	1.0.10
RUSTSEC-2026-0387	crypto-bigint	0.5.5	0.7.6 (no 0.5.x fix)
RUSTSEC-2026-0367 / 0368 / 0369	zip	8.6.0	9.0.0

This PR fixes the first three. The last two cannot be fixed in the lockfile; see "What remains" below.

What was done?

Three targeted cargo update -p <crate>@<old> --precise <new> calls, so nothing else re-resolved:

rustls-webpki      0.103.15 -> 0.103.16
webpki-roots       1.0.7    -> 1.0.11
webpki-root-certs  1.0.7    -> 1.0.11

git diff Cargo.lock is exactly these three entries (version and checksum); their dependency lists are unchanged.

1.0.11 is the latest webpki-roots release (the advisory is fixed from 1.0.10; 1.0.11 drops two more eMudhra roots tracked by the same Mozilla bug). Trust-store changes from 1.0.7 to 1.0.11, from the upstream release notes:

• Removed: emSign ECC Root CA - G3, emSign Root CA - C1, emSign ECC Root CA - C3, SecureSign Root CA12, Atos TrustedRoot 2011
• Added: Telia EC TLS Root CA v3, Telia RSA TLS Root CA v3, SECOM TLS ECC Root CA 2024, SECOM TLS RSA Root CA 2024

Where the crates are used:

• rustls-webpki is used by rustls (tonic, reqwest, hyper-rustls).
• webpki-roots is used by tonic (dapi-grpc, rs-dapi-client, dash-sdk and everything above it), reqwest/hyper-rustls (rs-dapi, rs-sdk-trusted-context-provider) and ureq (rs-scripts, the tenderdash-proto build script).
• webpki-root-certs is only in the lockfile: its one user, rustls-platform-verifier, is an optional dependency that no workspace crate enables on any target (cargo tree -i webpki-root-certs --target all finds nothing). It is bumped anyway because cargo audit reads Cargo.lock.

What remains (4 vulnerabilities) and why

zip 8.6.0 (RUSTSEC-2026-0367 / 0368 / 0369, 3 of the 4). Comes only from tenderdash-proto-compiler, a build dependency of tenderdash-proto at rs-tenderdash-abci tag v1.8.0. It is used at build time to unpack the Tenderdash proto files, not at runtime. dashpay/rs-tenderdash-abci#221 moved it to zip 9 and is released as tag v1.8.1 (2026-10-23; v1.8.0 plus that bump and CI changes, still building against Tenderdash v1.8.0 protos). Clearing it needs the tag bumped from v1.8.0 to v1.8.1 in packages/rs-drive-abci/Cargo.toml, packages/rs-drive-proof-verifier/Cargo.toml and packages/dapi-grpc/Cargo.toml. That is a Cargo.toml change to the ABCI library, so it is left for a separate PR.

crypto-bigint 0.5.5 (RUSTSEC-2026-0387). Fixed only in 0.7.6+; there is no 0.5.x release with the fix. It comes from elliptic-curve 0.13.8 (and vsss-rs 5.1.0), pulled in by blstrs_plus 0.8.18 -> blsful (dashpay/agora-blsful) -> dashcore (rust-dashcore). No compatible release removes it:

• elliptic-curve 0.13.8 is the last 0.13.x and requires crypto-bigint 0.5.
• Even the newest blstrs_plus 0.9.0 (used by upstream blsful 4.x) still depends on elliptic-curve ^0.13.8 next to ^0.14, so moving the BLS stack to the 4.x line would not drop crypto-bigint 0.5 either.

A fix has to start upstream in blstrs_plus and then flow through agora-blsful and rust-dashcore. No audit.toml ignore is added for it.

Warnings (unchanged, "allowed", do not fail the job)

atomic-polyfill 1.0.3 (unmaintained), lru 0.16.4, scc 2.4.0 and tokio 1.52.3 (RUSTSEC-2026-0386, AsyncFd I/O safety, fixed in tokio >= 1.53.3) are reported as warnings before and after this PR.

How Has This Been Tested?

cargo audit (cargo-audit 0.22.2, the version the workflow pins), advisory DB fetched 2026-10-26.

Before (v5.0-dev at 7ea82c7):

Crate:     crypto-bigint      Version: 0.5.5     ID: RUSTSEC-2026-0387
Crate:     rustls-webpki      Version: 0.103.15  ID: RUSTSEC-2026-0382
Crate:     webpki-root-certs  Version: 1.0.7     ID: RUSTSEC-2026-0383
Crate:     webpki-roots       Version: 1.0.7     ID: RUSTSEC-2026-0381
Crate:     zip                Version: 8.6.0     ID: RUSTSEC-2026-0367
Crate:     zip                Version: 8.6.0     ID: RUSTSEC-2026-0368
Crate:     zip                Version: 8.6.0     ID: RUSTSEC-2026-0369
error: 7 vulnerabilities found!
warning: 4 allowed warnings found

After (this PR):

Crate:     crypto-bigint      Version: 0.5.5     ID: RUSTSEC-2026-0387
Crate:     zip                Version: 8.6.0     ID: RUSTSEC-2026-0367
Crate:     zip                Version: 8.6.0     ID: RUSTSEC-2026-0368
Crate:     zip                Version: 8.6.0     ID: RUSTSEC-2026-0369
error: 4 vulnerabilities found!
warning: 4 allowed warnings found

Build check on the workspace crates that compile the changed crates (tonic, reqwest, hyper-rustls, ureq, rustls):

cargo check --locked -p dapi-grpc -p rs-dapi -p rs-sdk-trusted-context-provider -p rs-scripts

Finished `dev` profile [unoptimized + debuginfo] target(s) in 5m 11s

The log shows rustls 0.23.46, rustls-webpki 0.103.16, webpki-roots 1.0.11, tonic, reqwest and ureq compiled, with no new warnings.

No test suites were run: the change is three patch-version bumps of certificate-checking crates with no API change.

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed
• If I added or changed GroveDB structure, I described it in the area's structure.rs, regenerated grovedb-structure.json, and checked the structure viewer link posted on this pull request

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

PR Hygiene · 7f824d7

• Bots — coderabbitai not yet · thepastaclaw ✓ — /skip-bots proceeds without the ones not yet reported
• Self-review — post /self-reviewed
• Build green
• Approvals — you own every area touched; none needed

When every merge requirement is met, the PR Hygiene check passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters: 1

• Cargo.lock is excluded by !**/*.lock

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

Run configuration

• Source mode: Auto
• Repository: dashpay/platform
• Branch: chore/bump-webpki-rustsec-2026-0381
• File: .coderabbit.yaml
• Commit: 7f824d7
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: f4fcbac0-5c21-49d1-a6a0-92db51a3b41b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Waiting for bot review — coderabbitai not yet · thepastaclaw ✓. Wait for the missing reviews, or a writer can post /skip-bots to proceed without them; blocking findings still need addressing.
Full checklist in the description.

[thepastaclaw]

✅ Final review complete — no blockers (commit 7f824d7) · triage: low

[thepastaclaw]

Final validation — Phase 1 + Phase 2

The root Cargo.lock update is correctly limited to the three intended TLS dependency upgrades, and the available CI results show no related failure. However, the repository also commits a stale packages/wasm-drive-verify/Cargo.lock containing rustls-webpki 0.103.3; although the root workspace build ignores it, repository-wide security scanners can still report the advisory. This is a non-blocking scope-completeness issue for the security bump.

🟡 1 suggestion(s)

1 finding(s) not shown inline (the lines are not part of this PR's diff)

🟡 Suggestion: Committed WASM lockfile still pins vulnerable rustls-webpki
packages/wasm-drive-verify/Cargo.lock:3084-3087

This committed lockfile still pins rustls-webpki 0.103.3, below the 0.103.16 version that fixes RUSTSEC-2026-0382. wasm-drive-verify is listed as a member of the root workspace, and its build script uses the root Cargo.lock, so this stale lockfile does not affect the normal workspace build. It can nevertheless be discovered by tools that scan every committed lockfile, leaving the repository with an apparently unresolved vulnerable pin despite this security-focused update. Delete the vestigial lockfile if it is no longer supported, or regenerate it from the appropriate manifest and update the vulnerable entry.

_{source: glm-5.3-flash (phase1-reviewer: general)}

Review provenance

Source: reviewer 1: glm-5.3-flash (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: low by gpt-6.1-sol (effort low) — This is a tightly scoped Cargo.lock-only dependency refresh with no source or consensus changes, and its correctness is straightforward to verify from the exact package version and checksum updates.
• Phase 1 reviewers: glm-5.3-flash — general (completed, effort high); agent phase1-reviewer
• Phase 1 model: glm-5.3-flash — zai quota: 5h 100% left, weekly 100% left; passed over gemini-3.8-flash-high (antigravity quota lookup failed)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort medium); agent phase2-reviewer, gpt-6.1-sol — architecture-layering (completed, effort medium); agent phase2-reviewer, gpt-6.1-sol — security-auditor (completed, effort medium); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/wasm-drive-verify/Cargo.lock`:
- [SUGGESTION] packages/wasm-drive-verify/Cargo.lock:3084-3087: Committed WASM lockfile still pins vulnerable rustls-webpki
  This committed lockfile still pins rustls-webpki 0.103.3, below the 0.103.16 version that fixes RUSTSEC-2026-0382. wasm-drive-verify is listed as a member of the root workspace, and its build script uses the root Cargo.lock, so this stale lockfile does not affect the normal workspace build. It can nevertheless be discovered by tools that scan every committed lockfile, leaving the repository with an apparently unresolved vulnerable pin despite this security-focused update. Delete the vestigial lockfile if it is no longer supported, or regenerate it from the appropriate manifest and update the vulnerable entry.