sec: replace two allow-list reasons with what the call sites actually say #486
2026-10-26
sec: replace two allow-list reasons with what the call sites actually say
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 7s
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 2m22s
The advisory gate's allow list is only worth what its reasons are worth, and
two of mine were generalisations I had checked in one place and then written as
if they held everywhere. Both happen to be correct; neither was verified where
it mattered. Re-checked by call site:
`rsa` RUSTSEC-2023-0071 (Marvin) — no fixed release exists, so this entry
cannot be bumped away and the reason carries the whole weight. I had written
"no private-key decryption here" after verifying it for openpay, whose
dependency turned out to be unused and was removed. The two copies that remain
were not checked at the time:
- sandbox-rs: `sandbox-tee/src/amd_kds.rs` is the only direct user of `rsa`
in the tree. It verifies AMD's KDS chain (ARK -> ASK -> VCEK, RSASSA-PSS /
SHA-384) with `RsaPublicKey` + `pss::VerifyingKey` + `Verifier`. Public-key
verification, no decryption, and `RsaPrivateKey` appears only inside
`#[cfg(test)] mod tests`, minting throwaway keys for a synthetic chain.
Marvin needs private-key PKCS#1 v1.5 decryption, which is absent.
- wai-rs: reaches `rsa` only through `c2pa`, an optional dependency behind
the `c2pa_emit` feature and off by default, so a default build never
compiles it.
`crypto-bigint` RUSTSEC-2026-0387 — I had recorded this as debt "on paths that
sign and derive keys", which overstated it. `elliptic-curve` is the only
dependent in all five lockfiles, and none of our own signing goes through it:
WAI, sandbox and jouleclaw sign with Ed25519 (`ed25519_dalek` /
curve25519-dalek, which does not use crypto-bigint). In wai-rs the
elliptic-curve path is again under optional `c2pa`, where production callers
supply their own signer and the in-tree `EphemeralSigner` holds a per-call key
that reaches `ValidationState::Valid` and never `Trusted`. A timing attack of
this class recovers a key by observing many operations under the same secret,
so a per-call key bounds it. The 0.5 pin is still real debt — reaching >=0.7.6
means moving the p256/elliptic-curve stack — but it is not sitting under a
long-lived key of ours.
No behaviour change: 47 lockfiles, the same 15 allowances, self-test green on
all six cases. This is the reasoning catching up with the gate.
Co-Authored-By: Claude Opus 5 <[email protected]>