Update rusty crystals

[illuzen]

upgraded some other packages to reduce (not eliminate) various cargo audit issues

---

Note

Medium Risk
Touches P2P DNS resolution and the miner QUIC/TLS path; dependency major/minor bumps could affect connectivity or certificate handling at runtime.

Overview
Bumps Quantus rusty-crystals crates (qp-rusty-crystals-hdwallet 2.4.0, dilithium 2.5.0 in the lockfile) and aligns related crypto/DNS deps (qp-poseidon-core 2.1.0 only, x509-parser 0.18.1, hickory-resolver 0.26.1).

litep2p is updated for Hickory 0.26: resolver construction drops TokioConnectionProvider, treats TokioResolver::build() as fallible, and broadens CannotReadSystemDnsConfig to a boxed error. Tests mirror the same builder pattern.

The node miner QUIC server moves to quinn 0.11 with rustls 0.23 and rcgen 0.13—self-signed TLS material uses rustls::pki_types, and the endpoint is created via QuicServerConfig::try_from. Workspace quinn is pinned at 0.11.9 and older quinn/rustls 0.21 stacks are removed from the lockfile to reduce cargo audit noise.

^{Reviewed by Cursor Bugbot for commit 8c82dcb. Configure here.}

[n13]

I've completed the review. You're now on branch pr-581 with a clean working tree (all my audit/update probing was dry-run; nothing was modified).

PR #581 Review — "Update rusty crystals"

cargo audit before/after (the headline)

	main (before)	pr-581 (after)
Vulnerabilities	31	27
Warnings (unmaintained / unsound / yanked)	14 / 6 / 2	13 / 6 / 2

Resolved by this PR (5 advisory instances):

• RUSTSEC-2026-0009 — time 0.3.44 DoS (stack exhaustion) → time bumped
• RUSTSEC-2026-0037 — quinn-proto 0.10.6 DoS → old quinn 0.10 stack removed
• RUSTSEC-2026-0118 — hickory-proto 0.25.2 NSEC3 unbounded loop (no upstream fix exists)
• RUSTSEC-2026-0119 — hickory-proto 0.25.2 CPU exhaustion
• RUSTSEC-2025-0134 — rustls-pemfile 1.0.4 unmaintained → dropped via rustls 0.23 move

No new advisories introduced. The rustls 0.21 stack is fully gone (now a single rustls 0.23.32), which is a nice cleanup.

Code correctness — looks good

I verified each migration against the actual crate APIs:

• litep2p / hickory 0.26: TokioResolver::builder_with_config(cfg, Default::default()), fallible .build(), and the boxed CannotReadSystemDnsConfig(Box<dyn Error + Send + Sync>) are all consistent with the 0.26 API. The .into() conversions for both the read_system_conf() and build() error paths are correct. Tests mirror the same pattern.
• miner QUIC (quinn 0.11 / rustls 0.23 / rcgen 0.13) in node/src/miner_server.rs:
  • CertificateDer::from(cert.cert) — confirmed impl From<Certificate> for CertificateDer exists in rcgen 0.13.2. ✓
  • PrivateKeyDer::try_from(cert.key_pair.serialize_der()) — pki-types sniffs the DER (rcgen emits PKCS#8) so this resolves correctly. ✓
  • rustls::ServerConfig::builder() auto-selects a crypto provider. I checked the unified lockfile: aws-lc-rs is absent, rustls 0.23.32 pulls only ring 0.17.14, so provider selection is unambiguous — no runtime "multiple providers" panic risk. ✓
  • Dropping dangerous_configuration/quic rustls features is safe: the node only runs the QUIC server (no client/dangerous verifier in this repo), and disabling tls12 is fine since QUIC mandates TLS 1.3. ✓
  • Migration is complete — no leftover rustls::Certificate/PrivateKey/with_safe_defaults/old-quinn APIs anywhere.

Findings / recommendations

1. High-value, easy miss — the headline quinn DoS isn't actually fixed. The PR moves to quinn 0.11 but lands on quinn-proto 0.11.13, while RUSTSEC-2026-0037 (8.7 high DoS) requires >=0.11.14. This quinn-proto is pulled solely by the node's own quinn 0.11.9, so it's fully in this PR's control. I dry-ran the fix: cargo update -p quinn-proto bumps 0.11.13 → 0.11.14 (semver-compatible, lockfile-only, no other changes) and would clear it. Recommend adding this before merge — it's the one remaining issue the PR can fully own.

2. hickory-proto 0.24.4 still flagged (RUSTSEC-2026-0119) — out of scope. It comes transitively via hickory-resolver 0.24.4 → libp2p-dns → libp2p 0.54.1 → sc-telemetry (polkadot-sdk), not the litep2p path this PR fixed. Can't be resolved without a substrate/libp2p bump. Worth a note in the PR description so the claim "aligns hickory-resolver 0.26.1" isn't read as fully clearing the hickory advisory.

3. Minor: the lockfile keeps a duplicate rcgen 0.11.3 (transitive) alongside the node's rcgen 0.13.2. Harmless, just noise.

4. Remaining audit noise (wasmtime 35.0.0 cluster, ring 0.16.20, tokio 0.2.25, rustls-webpki 0.101.7 — which isn't even in the resolved tree for this platform) is all transitive from polkadot-sdk and outside this PR's scope, consistent with the author's "reduce, not eliminate" framing.

Verdict

Solid, well-contained dependency bump. Code changes are correct and the migration is complete; CI's heavy build/test matrix was still pending when I checked, so confirm those go green. The one thing I'd push to include before merge is the trivial quinn-proto → 0.11.14 bump so the quinn DoS that motivated the quinn upgrade is actually closed.

Want me to apply the quinn-proto lockfile bump on this branch?

[n13]

LGTM now

Claude noted some lockfile deps were downgraded, but they only affect windows?

The lockfile also shows several windows-sys downgrades (0.61.0 → 0.59.0/0.48.0) on crates like mio/rustix/tempfile. These are cfg(windows)-only deps, so they don't affect the Linux/macOS node build or the audit on our targets — just noting it as lockfile churn from the regeneration.