1+ # RUSTSEC-2026-0049: CRL revocation checking bug in rustls-webpki 0.101.7.
2+ #
3+ # Background: CRL (Certificate Revocation List) checking is an optional TLS
4+ # feature where a client fetches a list of revoked certificates from URLs
5+ # embedded in the cert itself, to confirm it hasn't been invalidated since
6+ # issuance. This is distinct from normal certificate validation.
7+ #
8+ # The bug: when a cert lists multiple CRL distribution point URLs, only the
9+ # first URL is checked; the rest are silently ignored. This matters only when
10+ # CRL checking is enabled AND the UnknownStatusPolicy is set to Allow (meaning
11+ # "if I can't determine revocation status, accept the cert anyway"). With that
12+ # combination, a revoked certificate from a compromised CA could be accepted.
13+ #
14+ # Why this does not affect Commit-Boost: the vulnerable code path is never
15+ # reached because no code in this codebase enables CRL checking at all.
16+ # TLS is used in four places: (1) relay communication via reqwest with
17+ # rustls-tls uses default CA validation with no CRL configured; (2) the signer
18+ # server presents a TLS certificate but does not check client revocation;
19+ # (3) the signer client pins a single self-signed certificate via
20+ # add_root_certificate — CRL is irrelevant for self-signed certs; (4) the Dirk
21+ # remote signer uses mTLS with a custom CA but again no CRL. In all cases the
22+ # buggy CRL code in rustls-webpki is never invoked.
23+ #
24+ # Blocked on sigp/lighthouse upgrading past v8.0.1 without a compilation
25+ # regression (SseEventSource missing cfg guard in eth2 error.rs).
26+ [advisories ]
27+ ignore = [" RUSTSEC-2026-0049" ]
0 commit comments