sec: replace two allow-list reasons with what the call sites actually say #486
Loading…
Reference in a new issue
No description provided.
Delete branch "sec/allow-reasons-verified"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The advisory gate from #443 is only worth what its reasons are worth. Two of mine were generalisations — checked in one place, then written as though they held everywhere. Both turn out to be correct; neither was verified where it mattered. This replaces them with what the call sites say.
rsaRUSTSEC-2023-0071 (Marvin)The only finding with no fixed release at all, so the reason carries the whole weight rather than buying time until a bump.
I wrote "no private-key decryption here" after checking openpay — whose dependency turned out to be unused and was removed outright. The two remaining copies were not checked then:
sandbox-tee/src/amd_kds.rsis the only direct user ofrsain the tree. It verifies AMD's KDS chain (ARK → ASK → VCEK, RSASSA-PSS/SHA-384) withRsaPublicKey+pss::VerifyingKey+Verifier. Public-key verification; no decryption anywhere;RsaPrivateKeyappears only inside#[cfg(test)] mod tests, minting throwaway keys for a synthetic chain. Marvin targets private-key PKCS#1 v1.5 decryption, which is absent.rsaonly throughc2pa, an optional dependency behind thec2pa_emitfeature withdefault-features = false, so a default build never compiles it.crypto-bigintRUSTSEC-2026-0387I recorded this as debt "on paths that sign and derive keys". That overstated it.
elliptic-curveis the only dependent in all five lockfiles, and none of our own signing runs 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 optionalc2pa, where production callers supply their own signer and the in-treeEphemeralSignerholds a per-call key reachingValidationState::Validand neverTrusted.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 remains 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. Comments and two reason strings only.
🤖 Generated with Claude Code
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]>