`joule-code-collab` dev-depended on openmls 0.6 / openmls_rust_crypto 0.3 while
`joule-moq-mls` runs openmls 0.9.1 / 0.6.0 in production. Two generations apart
meant a second, older MLS implementation in the test graph, and with it
hpke-rs 0.2.0: RUSTSEC-2026-0071 (nonce reuse in an HPKE context, 9.3), -0070
(incorrect length encoding on KDF export, 8.2), -0069 and -0072 (missing
all-zero X25519 shared-secret check).
Nothing shipped it — the edge is `[dev-dependencies]` only — but there is no
reason to test RFC 9420 against an implementation production does not use, and
"it is only in the test graph" is a weaker answer than not having it. Pinning
the dev-deps to the production generation removes hpke-rs 0.2.0,
hpke-rs-crypto 0.2.0, hpke-rs-rust-crypto 0.2.0 and openmls 0.6.0 outright.
One API change: openmls 0.9 takes the crypto backend rather than the whole
provider in `export_secret`, which is the call joule-moq-mls already makes.
`tests/mls_keying.rs` passes.
The four allow-list entries are removed with them, which is the check working
as intended: an entry that no longer matches anything fails the run, so an
excuse cannot outlive the exposure it was written for.
Also corrects two allow-list reasons that overstated the remaining quick-xml
exposure. I had recorded the openpay 0.37.5 copy as a live exposure on the ISO
20022 ingestion path. It is not: `open-payments-iso20022 1.0.10` declares
quick-xml but never calls it — the crate ships serde-annotated types (3 files,
~2.2k lines, no `quick_xml` reference anywhere) and the parsing is ours, in
op-iso20022's codec, which binds the workspace 0.41. The copy is compiled and
never executed. The smart-byte 0.39.4 copy parses macOS plists via iroh, not
counterparty XML.
Co-Authored-By: Claude Opus 5 <[email protected]>
adf5774f9d