security-audit is a REQUIRED context, red on main, so every merge bypasses it — 2 real advisories (lopdf 7.5 HIGH, rkyv), and #7412 does not fix them

[proggeramlug]

security-audit is a REQUIRED context and has been red on main

That combination is the worst of the gate hazards: a required check that cannot pass means every merge bypasses it, so the gate stops being a gate while still looking like one on the Actions page. CLAUDE.md names this pattern ("REQUIRED + red job ⇒ every merge bypasses"); this is a live instance, and it has been failing on the last six completed main runs.

I merged ~45 PRs today with admin bypass, all of which passed over this.

Two real advisories, not just unmaintained-crate noise

RUSTSEC-2026-0187  severity 7.5 (HIGH)
  lopdf 0.39.0  <- printpdf 0.9.1 <- perry-ext-pdf
  Solution: upgrade to >= 0.42.0

RUSTSEC-2026-0235
  rkyv 0.7.46  "Insufficient archive validation can cause out-of-bounds
                reads in archives containing Rc/Arc"   (2026-05-13)
  <- rust_decimal 1.42.1 <- perry-stdlib
  Solution: upgrade to >= 0.8.17

Plus eight unmaintained/unsound/yanked warnings (atty, paste, proc-macro-error{,2}, rustls-pemfile, ttf-parser, event-listener, spin) which are lower priority but contribute to the red.

The open dependabot PR does NOT fix the high-severity one

#7412 ("bump printpdf from 0.9.1 to 0.10.1") looks like the fix and is not. I checked out its branch: printpdf moves to 0.10.1 but lopdf stays pinned at 0.39.0, the vulnerable version. Merging it would leave RUSTSEC-2026-0187 open while appearing to address it — worth knowing before someone merges it as a security fix.

Getting to lopdf >= 0.42 needs either a printpdf release that depends on it, or dropping/replacing perry-ext-pdf's use of it.

rkyv reaches us only through rust_decimal, which is a much smaller surface — a rust_decimal bump that moves to rkyv 0.8 is likely the cheap half of this.

Also worth deciding

Is perry-ext-pdf on the critical path? If the PDF extension is optional and rarely built, the exposure is different from a runtime-wide dependency, and that should be recorded in the decision rather than implied by silence.

Suggested acceptance

• cargo audit clean, or every remaining finding explicitly accepted in an ignore-list with a dated rationale (the mechanism cargo-deny already supports).
• Then confirm security-audit goes green on main at least once — a required context that has never been observed green is indistinguishable from one that is broken.

[proggeramlug]

Closing against the issue's own acceptance criteria, both now met:

1. Every remaining finding is fixed or explicitly accepted with rationale. cargo audit with the workflow's ignore set passes locally (9 allowed warnings, zero vulnerabilities). The ignore list in security-audit.yml carries a dated rationale per ID: RUSTSEC-2026-0187 (lopdf HIGH — no actionable upstream bump: printpdf's releases still pin lopdf ^0.39, and as the issue itself established, #7412 does not fix it despite looking like it does), RUSTSEC-2026-0235 (rkyv — not in the build graph: optional feature of rust_decimal that nothing enables, cargo tree -e normal -i rkyv matches nothing), plus the pre-existing rsa/hickory-proto entries.

2. security-audit has been observed green on main — three success runs on 2026-08-07 (07:15, 07:32, 07:34 UTC), not just once. The newest runs sit queued behind the Actions backlog, which is a queue problem, not a gate problem.

On the exposure decision the issue asked for: perry-ext-pdf is an optional extension crate, not runtime-core; the lopdf advisory (stack overflow on deeply nested PDF objects) is reachable only by programs that compile the PDF extension and parse untrusted PDFs. Recorded here as accepted-with-tracking: the ignore should be deleted the day a printpdf release depends on lopdf >= 0.42.

The remaining structural risk moved to its own tracker: a required context that is red gets bypassed by every admin merge — that pattern is #7582's territory (suppressions that outlive their subject) and today it was live again with a different gate (#7593: the baseline check could never pass because its README markers had been deleted).