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 #7555

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.