From d374e5b0261767588fd721fc0299cc19b181ae82 Mon Sep 17 00:00:00 2001 From: Noah Gift Date: Tue, 1 Sep 2026 13:04:52 +0200 Subject: [PATCH] fix(security): RUSTSEC-2026-0273 (manzana stubbed crypto) reds ci/security on every open PR Same signature as #2805: all PRs red, nothing changed in-repo. The advisory was committed to the RustSec DB at 2026-09-01T07:50:30Z -- two seconds after crates.io yanked manzana at 07:50:28Z. `ci / security` passed on #2825 at 06:44Z and has failed on #2836/#2837/ #2838 from 09:56Z. An advisory-DB catch-up, not a regression. CONTAINMENT ONLY. The block records the removal condition, and it is NOT "when a new manzana ships" -- see below. Reachability measured on a clean origin/main worktree, x86_64 Linux, absolute cargo binary (a `cargo` shell function on the dev box shadows it and redirects CARGO_TARGET_DIR): cargo tree -p aprender-gpu | grep -c manzana -> 0 cargo tree -p aprender-gpu --features metal | grep -c manzana -> 0 cargo tree --workspace | grep -c manzana -> 0 git grep -l 'secure_enclave|SecureEnclave' -- '*.rs' -> 0 files The middle line is load-bearing: manzana is BOTH optional AND declared under [target.'cfg(target_os = "macos")'.dependencies], so enabling `metal` on Linux pulls in nothing. aprender's only three call sites are `manzana::metal::*`, all behind cfg(all(target_os = "macos", feature = "metal")). The advisory is about `secure_enclave::SecureEnclaveSigner`, which this workspace never names. As with the h2 entry above it, cargo-deny passes WITHOUT an exemption because it walks the ACTIVATED graph; cargo-audit scans Cargo.lock, which lists target- and feature-gated deps unconditionally. So the ignore goes in .cargo/audit.toml ONLY -- adding it to deny.toml would be a dead exemption and fail check_deny_exemptions_live.sh. WHY AN IGNORE AND NOT AN UPGRADE. Both published versions (0.1.0, 0.2.0) are YANKED, so crates.io reports max_version 0.0.0 and there is nothing to bump to. More importantly the advisory carries `[versions] patched = []` -- NO version is considered fixed, so publishing a corrected manzana does NOT clear this gate on its own. Only amending the upstream advisory to name a patched range does. The removal condition is written that way in the file. VERIFICATION, STATED HONESTLY. This is NOT locally verified green. cargo-audit 0.22.1 on this x86_64 host does not report RUSTSEC-2026-0273 at all -- manzana surfaces only as `Warning: yanked` -- so a local run passes with OR without this ignore and proves nothing. The negative control was run and it FAILED TO FAIL, which is how the vacuity was found rather than shipped. The fix is sound by construction (CI errors on that exact id; `--ignore ` suppresses that id) and CI is the verifier. Refs #2805. Co-Authored-By: Claude Opus 5 --- .cargo/audit.toml | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/.cargo/audit.toml b/.cargo/audit.toml index dbc4ee6b1..b8e5bfefc 100644 --- a/.cargo/audit.toml +++ b/.cargo/audit.toml @@ -137,4 +137,39 @@ ignore = [ # cargo tree --workspace | grep -cE "h2 v0.3" -> 0 # REMOVE WHEN aws-smithy-http-client drops hyper 0.14. "RUSTSEC-2026-0258", # h2 0.3.27 via optional s3 feature only + + # manzana 0.2.0 stubbed cryptography. CONTAINMENT ONLY - remove per the + # condition at the bottom of this block, which is NOT "when a new manzana + # ships". + # + # The advisory is about `manzana::secure_enclave::SecureEnclaveSigner`, whose + # sign() derives a "signature" from public values only and whose verify() + # merely recomputes sign() and compares. aprender does not touch any of it. + # Reachability measured on a clean origin/main worktree, x86_64 Linux, using + # the absolute cargo binary (a `cargo` shell function on the dev box shadows + # it and silently redirects CARGO_TARGET_DIR): + # cargo tree -p aprender-gpu | grep -c manzana -> 0 + # cargo tree -p aprender-gpu --features metal | grep -c manzana -> 0 + # cargo tree --workspace | grep -c manzana -> 0 + # git grep -l 'secure_enclave|SecureEnclave' -- '*.rs' -> 0 files + # The middle line is the load-bearing one: manzana is BOTH optional and + # declared under [target.'cfg(target_os = "macos")'.dependencies], so + # enabling `metal` on Linux still pulls in nothing. aprender's only three + # call sites are `manzana::metal::*` in aprender-gpu/src/backend/mod.rs, + # every one behind cfg(all(target_os = "macos", feature = "metal")). + # As with the h2 entry above, cargo-deny already passes without an exemption + # because it walks the ACTIVATED graph; cargo-audit scans Cargo.lock, which + # lists target- and feature-gated deps unconditionally. + # + # WHY AN IGNORE RATHER THAN AN UPGRADE. Both published versions (0.1.0 and + # 0.2.0) are YANKED, so there is nothing to bump to - `max_version` on + # crates.io reads 0.0.0. More importantly the advisory carries + # `[versions] patched = []`, which means NO version is considered fixed: + # publishing a corrected manzana does NOT clear this gate on its own. Only + # amending the upstream advisory to name a patched range does. + # + # REMOVE WHEN either the advisory gains a patched range and this workspace is + # on a version inside it, or the manzana dependency is dropped from + # aprender-gpu entirely. Publishing a new manzana alone is NOT the condition. + "RUSTSEC-2026-0273", # manzana 0.2.0 stubbed crypto; unreachable here, see above ]