ci(deny): wildcards deny, advisory tracking, document multi-version debt

[ConYel]

Summary

• Base branch: master
• What changed and why:
  • deny.toml wildcards: allow → deny — catches any future * version requirements. Safe today (none exist).
  • .cargo/audit.toml: added structured comments and tracking TBD to all 18 advisory ignores — was completely undocumented, making it impossible to track when ignores can be removed.
  • deny.toml wasmtime ignores: added tracking TBD to all 11 entries — same reason.
  • deny.toml multiple-versions: left at "warn" with a TODO — tested "deny" locally and found 23 duplicate crate versions in the default feature set. Needs a separate dep cleanup sprint.
• Scope boundary: Only .cargo/audit.toml and deny.toml. No workflow changes, no code changes, no dependency bumps.
• Blast radius: None — these are config files consumed only by cargo deny check / cargo audit. Tighter policy (wildcards = "deny") will fail CI if someone adds a * dep, which is the intended effect.
• Linked issue: Closes the achievable parts of RFC RFC: Hardened CI pipeline — supply-chain scanning, provenance, and SBOM generation #7675 Phase 4. multiple-versions = "deny" remains blocked and documented.

Validation Evidence (required)

cargo deny check

Tail output:

advisories ok, bans ok, licenses ok, sources ok

• Commands run and tail output: cargo deny check — full output shows advisories ok, bans ok, licenses ok, sources ok with one expected advisory-not-detected warning for RUSTSEC-2026-0104 (rustls-webpki CRL panic, only active behind channel-mqtt feature).
• Beyond CI — what did you manually verify? Ran cargo deny check locally (the CI job). Also verified RUSTSEC-2024-0384 (instant unmaintained) by fetching the actual RustSec advisory page — real advisory, informational, no CVE.
• If any command was intentionally skipped, why: cargo fmt / cargo clippy / cargo test — not applicable, config-only changes.

Security & Privacy Impact

• New permissions, capabilities, or file system access scope? No
• New external network calls? No
• Secrets / tokens / credentials handling changed? No
• PII, real identities, or personal data in diff, tests, fixtures, or docs? No

Compatibility

• Backward compatible? Yes — wildcards = "deny" only triggers if someone adds a * dep.
• Config / env / CLI surface changed? No — same schema, same keys.

Rollback

git revert <sha> — low risk, no data or state changes.

[WareWolf-MoonWall]

Review — PR #8188 ci(deny): wildcards deny, advisory tracking, document multi-version debt

Author: ConYel
Head SHA: c07a435
Verdict: --approve
CI: 18/18 passing ✅
Active blocking reviews: None.

---

I reviewed the diff at c07a435, the full local deny.toml and the description of
.cargo/audit.toml, the existing advisory ignore rationale in both files, and the CI check
output. This is a config-hardening PR with no code changes. All three policy changes are
correct and CI confirms the workspace is clean against the tightened policy.

---

🟢 wildcards = "deny" is safe and correct

The diff changes wildcards = "allow" to wildcards = "deny" in deny.toml's [bans]
section. The PR body says "Safe today (none exist)" — verified by CI passing the bans ok
check with the new setting. This prevents future * version requirements from slipping
through undetected. The tightening is exactly right: it enforces a policy that should already
have been in place.

---

🟢 Advisory comments improve auditability significantly

Both deny.toml (wasmtime entries) and .cargo/audit.toml (all 18 entries) previously had
bare IDs or minimal comments with no tracking reference. The new format adds:

• Structured group headers (── wasmtime via extism 1.21.0 (14 advisories) ──)
• Rationale for each ignore (affected version, fix version, gating condition)
• tracking TBD placeholder on every entry that lacks an issue

This makes it possible, for the first time, to audit which ignores can be dropped after an
upstream release. The "tracking TBD" format is a process placeholder, not enforcement — but
it is strictly better than the prior state.

---

🟢 multiple-versions = "warn" deferral is correctly documented

The PR tested multiple-versions = "deny" locally, found 23 duplicate crate versions, and
left the value at "warn" with an explicit TODO and the count documented as of 2026-06-22.
This is the right decision: tightening to "deny" without cleaning up the duplicates would
break CI for everyone and should be done in a dedicated sprint. The deferral is intentional,
documented, and scoped.

---

🟡 Warning — "tracking TBD" entries have no enforcement mechanism

All 29 modified advisory ignores now carry tracking TBD instead of an actual issue URL.
The header comment says "Replace every tracking TBD with an actual issue URL once created."
Without a follow-up issue tracking the creation of these issues, this can silently stale for
months. Consider:

1. Filing a single meta-issue titled "Create tracking issues for all cargo-deny / audit
   ignores marked TBD" immediately after merge, and dropping its URL into the header comment.
2. Alternatively, adding a CI lint that fails if any tracking TBD string exists in
   deny.toml or .cargo/audit.toml after a grace period.

Neither is required before landing this PR, but without one the "tracking TBD" convention
risks becoming permanent boilerplate.

---

🟡 Warning — Advisory ignores in the deny.toml [advisories] section that were NOT

modified by this PR still lack tracking TBD

The PR updates the wasmtime entries in deny.toml. The pre-existing entries for
RUSTSEC-2025-0141 (bincode), RUSTSEC-2026-0097 (rand), RUSTSEC-2025-0134
(rustls-pemfile), RUSTSEC-2026-0104 (rustls-webpki CRL panic), and RUSTSEC-2024-0429
(glib) already had inline rationale in deny.toml and were not touched by this PR. They
now have a tracking story in deny.toml (inline reason text) but no tracking TBD marker
and no follow-up issue path. This inconsistency is a pre-existing condition and does not
block this PR, but should be addressed in the follow-up meta-issue above.

---

🔵 Suggestion — The count "23 duplicates with default features as of 2026-06-22" will become stale

The comment // 23 duplicates with default features as of 2026-06-22 is useful today but
will be wrong after any dependency bump. Consider phrasing it as:

# TODO: Change to "deny" once duplicate versions are resolved across the workspace.
# Last counted: 23 duplicates (default features, 2026-06-22). Run
# `cargo deny check bans 2>&1 | grep duplicate` to recount before re-attempting.
# Tracking: TBD

This gives the next engineer a command to run rather than an outdated number.

---

Template completeness

Section	Status
Summary	✅
Validation Evidence	✅ (cargo deny check with expected output shown)
Security & Privacy	✅
Compatibility	✅ (wildcards = "deny" only fails CI on future violations)
Rollback	✅ (low risk, git revert)
No AI trailers	✅
No bare string literals	✅ (config-only)