[neekolas]

Cargo-Deny on #4463 fails on three newly published libcrux panic advisories. Add an exception for each advisory, with the affected input, the patched version, the blocking dependency constraints, and the condition for removal.

A direct upgrade is blocked:

• cargo update -p libcrux-hmac-drbg --precise 0.0.2 fails because the pinned xmtp/openmls provider requires ^0.0.1.
• cargo update -p libcrux-kem --precise 0.0.10 fails because the current graph requires 0.0.9. The pinned xmtp/hpke-rs fork requires ^0.0.9, and hpke-rs-libcrux 0.7.0 requires =0.0.9.

The fixed releases do not satisfy these constraints. An upgrade requires coordinated changes to the crypto providers and their protocol compatibility validation. This PR uses the requested exception fallback. It changes only deny.toml; the manifests, lockfile, provider pins, and runtime code stay the same.

The upstream panic risks remain. In particular, malformed hybrid keys can still cause the decoder panic described by RUSTSEC-2026-0331. Remove the exceptions when the relevant providers accept the patched versions.

Advisories:

• RUSTSEC-2026-0329: auto-reseed requests with a nonzero output length divisible by 65,536 bytes; fixed in libcrux-hmac-drbg 0.0.2.
• RUSTSEC-2026-0330: short hybrid encapsulation seeds; fixed in libcrux-kem 0.0.10.
• RUSTSEC-2026-0331: short hybrid keys; fixed in libcrux-kem 0.0.10.

Validation:

• Reproduced all three advisory failures before the change.
• Confirmed that both direct upgrades fail dependency resolution.
• dev/nix-shell 'dev/agent-run cargo deny check advisories' passes after the change.
• dev/nix-shell 'just lint-config' passes after just install-js prepares the new worktree's release-tool fixtures.
• git diff --check passes.

After this PR merges, #4463 needs the updated base and a new push to test the fix. Rerunning the old job tests its old merge commit.

Note

Ignore 3 libcrux RUSTSEC advisories in cargo-deny config

Adds temporary ignore entries for RUSTSEC-2026-0329, RUSTSEC-2026-0330, and RUSTSEC-2026-0331 to the advisory config in deny.toml. Each entry names the affected libcrux dependency, the fixed version, and the currently pinned provider constraints as rationale. Risk: these advisories stay unreported until the pins are lifted; remove the ignores when libcrux is upgraded.

^{Macroscope summarized 9f142f5.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR only changes cargo-deny configuration, but it suppresses three known libcrux cryptographic panic advisories while the affected versions remain locked in the dependency graph. Because this weakens security CI validation for cryptography, human review is warranted.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

[P1] Keep the remotely reachable short-key panic blocking. libcrux-kem 0.0.9 remains locked, and a backend publisher can submit a parseable Welcome for any installation (TOPIC Known limitations; API admission checks only its framing and target). The client passes the unauthenticated HpkeCiphertext.kem_output to setup_receiver/Libcrux before AEAD authentication (crates/xmtp_mls_common/src/mls_ext/payload_encryption.rs::unwrap_payload_hpke), so a short hybrid output reaches the advisory's panic. A package owner can also advertise a short wrapper public key that a member later decodes when creating a Welcome. This suppresses the advisory gate while a remote denial-of-service path remains; no JOIN Known limitation or waiver accepts this risk.

Suggested fix: Keep RUSTSEC-2026-0331 blocking until the fixed dependency is available or exact KEM output/public-key lengths are checked before decoding on both paths. No diff: remediation spans runtime paths or an upstream dependency, not this config line alone.

^{Posted via Macroscope — Security}