Fix cargo audit: update 4 crates, add 21 new ignore entries (#54)

Updated dependencies:
- bytes 1.10.1 → 1.11.1 (RUSTSEC-2026-0007)
- rustls-webpki 0.103.4 → 0.103.13 (4 advisories)
- quinn-proto 0.11.13 → 0.11.14 (RUSTSEC-2026-0037)
- time 0.3.43 → 0.3.47 (RUSTSEC-2026-0009)

Rebuilt ignore list from scratch:
- Removed stale RUSTSEC-2024-0336 (no longer fires)
- Added 21 new entries for wasmtime, hickory-proto, rustls-webpki,
  keccak, and rand advisories with motivated comments
- Refreshed existing entries with updated comments

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: la10736

.cargo/audit.toml

@@ -1,39 +1,171 @@
 [advisories]
 ignore = [
-	# Coming from outdated libp2p and litep2p dependencies from which
-	# some Polkadot libraries are dependent on. They will be updated
-	# once we update Polkadot packages to latest version
-	"RUSTSEC-2024-0336",
-	"RUSTSEC-2024-0421",
-	"RUSTSEC-2025-0009",
-	"RUSTSEC-2024-0363", # Maybe we should fix the sqlx dependency in our frontier branch
-	# The next two coming from outdated wasmtime dependency from wich polkadot
-	# and substrate crates are dependent on. Unfortunally seams that also the
-	# newver versions still depend from the same wasmtime version.
-	"RUSTSEC-2023-0091", # LOW severity
-	"RUSTSEC-2024-0438", # Just affect Windows where devices are not fully sandboxed.
-	"RUSTSEC-2024-0442", # FROM THE VUNERABILITY DESCRIPTION
-    # Note: this is an internal-only crate in the Wasmtime project not intended for external
-    # use and is more strongly signaled nowadays as of bytecodealliance/wasmtime#10963.
-    # Please open an issue in Wasmtime if you're using this crate directly.
-    # ** We don't use this crate directly, so we can ignore it. **
-	"RUSTSEC-2025-0055", # coming from indirect dependency tracing-subscriber
-	"RUSTSEC-2025-0118", # coming from indirect dependency wasmtime v0.8.1.
-	# From https://rustsec.org/advisories/RUSTSEC-2025-0118 ->
-	# https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hc7m-r6v8-hg9q
-	# "This is a bug in Wasmtime's safe Rust API. It should not be possible to cause unsoundness
-	# with Wasmtime's embedding API if unsafe is not used. Embeddings which do not use the wasm
-	# threads proposal nor created shared memories nor actually share shared memories across
-	# threads are unaffected. Only if shared memories are created across threads might an
-	# embedding be affected."
-	# We fall in the case where we don't use wasm threads at all.
-	"RUSTSEC-2026-0002", # coming from indirect dependency in smoldot-light@v0.9.0 and libp2p-identify@0.43.1.
-	# For smoldot-light@v0.9.0, we looked into the code at https://github.com/smol-dot/smoldot.git@light-js-deno-v1.0.17;
-	# all the usage of `lru::LruCache` don't use `iter_mut()` or iterate over `&mut` cache reference.
-	# For the libp2p-identify@0.43.1, we looked into the code at https://github.com/libp2p/rust-libp2p.git@libp2p-identify-v0.43.1
-	# and in protocols/identify/src/behaviour.rs we can see that there isn't any mutable iterator used for
-	# `lru::LruCache`.
-	# We can conclude that the unsound code is never exercised.
+	# ===== libp2p / litep2p transitive dependencies =====
+
+	"RUSTSEC-2024-0421", # idna v0.4.0 — from libp2p v0.52.4 and litep2p v0.9.5.
+	# Punycode label acceptance issue. No compatible update; pinned by polkadot-sdk.
+
+	"RUSTSEC-2025-0009", # ring v0.16.20 — stale lockfile entry (libp2p-quic -> libp2p-tls -> rcgen -> ring 0.16).
+	# Nothing in the workspace actually depends on this chain (`cargo tree` confirms it).
+	# It remains in Cargo.lock because Cargo always resolves optional dependencies.
+
+	"RUSTSEC-2026-0037", # quinn-proto v0.10.6 — stale lockfile entry from libp2p-quic v0.10.3 optional feature.
+	# `cargo tree` shows nothing; only present in Cargo.lock via optional dependency resolution.
+
+	"RUSTSEC-2026-0118", # hickory-proto v0.25.2 — NSEC3 closest-encloser proof unbounded loop.
+	# From https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
+	# Transitive via litep2p v0.9.5 -> hickory-resolver v0.25.2. No fix available;
+	# even the latest litep2p still depends on hickory-proto 0.25.2.
+
+	"RUSTSEC-2026-0119", # hickory-proto v0.24.4 & v0.25.2 — O(n²) CPU exhaustion in name compression.
+	# From https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
+	# v0.24.4 from libp2p v0.54.1 -> libp2p-dns v0.42.0; v0.25.2 from litep2p v0.9.5.
+	# Fix requires hickory-proto >= 0.26.1; no compatible update in libp2p/litep2p yet.
+
+	# ===== rustls-webpki (pinned by major version boundaries) =====
+	# rustls-webpki 0.101.7 (via rustls 0.21.12 -> libp2p-websocket/hyper-rustls/jsonrpsee)
+	# and 0.102.8 (via rustls 0.22.4 -> jsonrpsee-client-transport) cannot be updated to
+	# the fixed 0.103.12+ without upgrading rustls across a major version boundary.
+	# The primary path (rustls 0.23.x -> webpki 0.103.13) is already fixed.
+
+	"RUSTSEC-2026-0049", # rustls-webpki v0.102.8 — CRL Distribution Point faulty matching logic.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0049
+	# Fix requires >= 0.103.10 which needs rustls >= 0.23.x. Pinned by jsonrpsee 0.22.5.
+
+	"RUSTSEC-2026-0098", # rustls-webpki v0.101.7 & v0.102.8 — URI name constraints incorrectly accepted.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0098
+	# Requires certificate misissuance with URI name constraints; low risk for P2P TLS.
+
+	"RUSTSEC-2026-0099", # rustls-webpki v0.101.7 & v0.102.8 — wildcard name constraint bypass.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0099
+	# Requires certificate misissuance; low risk for P2P TLS.
+
+	"RUSTSEC-2026-0104", # rustls-webpki v0.101.7 & v0.102.8 — reachable panic in CRL parsing.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0104
+	# Panic reachable before signature verification via malformed CRL. DoS risk in adversarial P2P,
+	# but update is blocked by major version boundary. Primary path (0.103.13) is already fixed.
+
+	# ===== sqlx (frontier dependency) =====
+
+	"RUSTSEC-2024-0363", # sqlx v0.7.4 — binary protocol misinterpretation via truncating casts.
+	# From frontier's fc-db. Should be fixed when updating the frontier fork.
+
+	# ===== tracing-subscriber (arkworks dependency) =====
+
+	"RUSTSEC-2025-0055", # tracing-subscriber v0.2.25 — ANSI escape sequence log poisoning.
+	# Via ark-relations v0.4.0 which unconditionally enables tracing-subscriber 0.2.x.
+	# This is an upstream arkworks issue; no patched version of ark-relations avoids it.
+
+	# ===== wasmtime v8.0.1 (polkadot-sdk via sc-executor-wasmtime v0.36.0) =====
+	# All wasmtime advisories below are from the outdated wasmtime v8.0.1 dependency
+	# pulled in by polkadot-sdk. Updating requires an upstream polkadot-sdk release.
+
+	# -- Already existing ignores (refreshed) --
+
+	"RUSTSEC-2023-0091", # wasmtime v8.0.1 — i64x2.shr_s miscompilation with constant input.
+	# LOW severity. Constant input requirement limits practical exploitation.
+
+	"RUSTSEC-2024-0438", # wasmtime v8.0.1 — Windows device filenames not fully sandboxed.
+	# Only affects Windows; our deployment targets Linux.
+
+	"RUSTSEC-2024-0442", # wasmtime-jit-debug v8.0.1 — JitDumpFile undefined memory dump.
+	# From https://rustsec.org/advisories/RUSTSEC-2024-0442
+	# Internal-only wasmtime crate not intended for external use. We don't use it directly.
+
+	"RUSTSEC-2025-0118", # wasmtime v8.0.1 — unsound API access to shared linear memory.
+	# From https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hc7m-r6v8-hg9q
+	# Only affects embeddings using the wasm threads proposal with shared memories across threads.
+	# Substrate explicitly sets config.wasm_threads(false) in sc-executor-wasmtime.
+
+	# -- Wasmtime: Component Model not used by Substrate --
+	# wasmtime 8.0.1 predates stable Component Model support.
+	# Substrate does not enable the Component Model.
+
+	"RUSTSEC-2026-0085", # wasmtime v8.0.1 — panic lifting flags component value.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0085
+	# Requires Component Model which Substrate does not use.
+
+	"RUSTSEC-2026-0091", # wasmtime v8.0.1 — OOB write transcoding component model strings.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0091
+	# Requires Component Model which Substrate does not use.
+
+	"RUSTSEC-2026-0092", # wasmtime v8.0.1 — panic with misaligned component model UTF-16 strings.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0092
+	# Requires Component Model which Substrate does not use.
+
+	"RUSTSEC-2026-0093", # wasmtime v8.0.1 — heap OOB read in component model UTF-16 transcoding.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0093
+	# Requires Component Model which Substrate does not use.
+
+	# -- Wasmtime: WASI not used by Substrate --
+	# sc-executor-wasmtime does not load WASI modules.
+
+	"RUSTSEC-2026-0020", # wasmtime v8.0.1 — guest-controlled resource exhaustion in WASI.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0020
+	# Requires WASI which Substrate does not use.
+
+	"RUSTSEC-2026-0021", # wasmtime v8.0.1 — panic in wasi:http/types.fields.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0021
+	# Requires WASI HTTP which Substrate does not use.
+
+	# -- Wasmtime: Winch compiler not used (Substrate uses Cranelift) --
+
+	"RUSTSEC-2026-0086", # wasmtime v8.0.1 — host data leakage with 64-bit tables and Winch.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0086
+	# Requires Winch compiler; Substrate uses Cranelift.
+
+	"RUSTSEC-2026-0089", # wasmtime v8.0.1 — host panic when Winch executes table.fill.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0089
+	# Requires Winch compiler; Substrate uses Cranelift.
+
+	"RUSTSEC-2026-0094", # wasmtime v8.0.1 — improperly masked table.grow return value with Winch.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0094
+	# Requires Winch compiler; Substrate uses Cranelift.
+
+	"RUSTSEC-2026-0095", # wasmtime v8.0.1 — Winch sandbox-escaping memory access.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0095
+	# Requires Winch compiler; Substrate uses Cranelift.
+
+	# -- Wasmtime: Requires non-default configuration --
+
+	"RUSTSEC-2026-0087", # wasmtime v8.0.1 — f64x2.splat segfault/OOB load on Cranelift x86-64.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0087
+	# Only triggers when signals_based_traps is DISABLED (non-default).
+	# Substrate uses wasmtime::Config::new() which has signals_based_traps enabled by default
+	# and never disables it. Therefore this code path is never exercised.
+
+	"RUSTSEC-2026-0088", # wasmtime v8.0.1 — data leakage between pooling allocator instances.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0088
+	# Requires pooling allocator with specific non-default config.
+	# Substrate uses on-demand (not pooling) instance allocation.
+
+	"RUSTSEC-2026-0096", # wasmtime v8.0.1 — miscompiled guest heap access on aarch64 Cranelift.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0096
+	# CRITICAL severity but only affects aarch64 architecture.
+	# Our primary deployment targets x86-64. Pinned by polkadot-sdk; no update path available.
+
+	# ===== lru (unsound — IterMut not exercised) =====
+
+	"RUSTSEC-2026-0002", # lru v0.12.5 — unsound IterMut via Stacked Borrows violation.
+	# Used by libp2p-identify v0.43.1 and smoldot-light v0.9.0 (polkadot-sdk transitive).
+	# We checked the source code: no mutable iterator (IterMut) is used on lru::LruCache
+	# in either crate. The unsound code path is never exercised.
+
+	# ===== keccak (unsound — asm feature not enabled) =====
+
+	"RUSTSEC-2026-0012", # keccak v0.1.5 — unsound ARMv8 assembly backend.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0012
+	# The ARMv8 assembly backend is opt-in via the `asm` feature flag.
+	# This feature is not enabled in any dependency in the workspace.
+	# The default pure-Rust implementation is not affected.
+
+	# ===== rand (unsound — custom logger not used) =====
+
+	"RUSTSEC-2026-0097", # rand v0.8.5 & v0.9.2 — unsound with custom logger using rand::rng().
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0097
+	# Only triggers when a custom logger implementation calls rand::rng() during ThreadRng
+	# reseeding. This project uses Substrate's standard sc-tracing logging infrastructure
+	# which does not call rand::rng(). The trigger conditions are not met.
 ]
 informational_warnings = ["unmaintained", "yanked"]
 

.claude/skills/cargo-audit/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: Cargo Audit Triage
+description: >
+  This skill should be used when the user asks to "run cargo audit",
+  "triage cargo audit", "fix audit vulnerabilities", "update audit.toml",
+  "check cargo audit ignores", "clean up audit ignore list",
+  "review audit.toml", "remove stale audit ignores", or mentions
+  resolving Rust security advisories or RUSTSEC identifiers. Provides a
+  systematic workflow for
+  analyzing each vulnerability, attempting updates, and writing motivated
+  ignore entries when updates are not possible.
+---
+
+# Cargo Audit Triage
+
+Systematic workflow for running `cargo audit`, analyzing each reported
+vulnerability, attempting dependency updates, and documenting justified
+ignores in `.cargo/audit.toml`.
+
+## Workflow Overview
+
+1. Read the existing `.cargo/audit.toml` ignore list for context
+2. Run `cargo audit`
+3. For each vulnerability, follow the resolution decision tree
+4. For existing ignore entries, verify they still fire
+
+## Step 1: Read Existing Ignore List
+
+Read `.cargo/audit.toml` before running the audit. Study the existing
+ignore entries and their motivations to understand the project's
+conventions and writing style for ignore comments.
+
+## Step 2: Run Cargo Audit
+
+```bash
+cargo audit
+```
+
+Collect all reported vulnerabilities (errors) and warnings. Separate them
+into:
+- **Vulnerabilities** (errors) — must be resolved or ignored with motivation
+- **Warnings** (unmaintained, yanked) — informational, no action required
+
+## Step 3: Resolve Each Vulnerability
+
+For each vulnerability, follow this decision tree in order.
+
+### 3a. Identify the Dependency Chain
+
+```bash
+cargo tree -i <crate>@<version> --depth 3
+```
+
+Determine whether the vulnerable crate is:
+- A **direct dependency** (listed in a workspace or crate `Cargo.toml`)
+- A **transitive dependency** (pulled in by another crate)
+
+If `cargo tree` reports "nothing to print", try `--target all --edges all`.
+If still nothing, the entry may be a **stale lockfile artifact** — verify
+by searching `Cargo.lock` directly:
+
+```bash
+grep -B30 '"<crate> <version>"' Cargo.lock | grep 'name ='
+```
+
+### 3b. Attempt to Update
+
+**Direct dependency with a patched version available:**
+Update the version in `Cargo.toml` to the fixed version and run
+`cargo check` to verify compatibility.
+
+**Transitive dependency with a compatible patched version:**
+Run `cargo update -p <crate>@<version>` to attempt an in-place update.
+Verify with `cargo audit` afterward.
+
+**Transitive dependency where the patched version is incompatible:**
+Check if the **parent crate** has a newer version that uses the patched
+dependency:
+
+```bash
+cargo search <parent-crate>
+cargo info <parent-crate>@<latest-version>
+```
+
+If a compatible parent update exists, update it. If the parent is pinned
+by an upstream framework (e.g., polkadot-sdk), updating may not be feasible.
+
+### 3c. Analyze the Advisory (When Update Is Not Possible)
+
+When no update path exists, perform a thorough analysis before ignoring:
+
+1. **Read the advisory page** at the URL from the audit output
+2. **Read the upstream security advisory** (usually linked from the
+   rustsec page, often a GitHub Security Advisory / GHSA)
+3. **Identify the trigger conditions** — what configuration, API usage,
+   or code path activates the vulnerability
+4. **Check the project's actual usage** — read the relevant source code
+   to verify whether the trigger conditions are met
+
+Common safe-to-ignore patterns:
+- Vulnerability requires a feature/config that is not enabled
+  (e.g., `wasm_threads(false)` means thread-related vulns don't apply)
+- Vulnerability affects a platform not targeted
+  (e.g., Windows-only issue on a Linux-only deployment)
+- Vulnerable code path is never exercised
+  (e.g., `IterMut` on a cache that is only read)
+- Crate is a stale lockfile entry not actually used by the workspace
+
+### 3d. Add Ignore Entry
+
+Add the advisory to `.cargo/audit.toml` with a **motivated comment**
+explaining:
+- Where the dependency comes from (the dependency chain)
+- A link to the advisory and/or upstream security advisory
+- **Why it is safe to ignore** — the specific condition that makes the
+  project unaffected
+
+Follow the comment style already present in the file. See
+`references/ignore-examples.md` for examples.
+
+## Step 4: Verify Existing Ignore Entries
+
+To clean up the ignore list:
+
+1. Remove **all** entries from the `ignore` list
+2. Run `cargo audit` with the empty list
+3. Note which advisories still fire
+4. Re-add only the entries that still fire, with refreshed comments
+5. Remove entries that no longer fire (dependency was updated or removed)
+
+## Ignore Comment Format
+
+Each ignore entry should follow this pattern:
+
+```toml
+"RUSTSEC-YYYY-NNNN", # <crate> v<version> — short summary of the chain.
+# Link to advisory and/or upstream security advisory.
+# Explanation of why it is safe to ignore in this project's context.
+```
+
+Keep comments concise but complete. The goal is that a future reader can
+understand the decision without re-investigating.
+
+## Additional Resources
+
+### Reference Files
+
+- **`references/ignore-examples.md`** — Real-world examples of well-motivated
+  ignore entries from a production Cargo workspace