Repository navigation
test: stop asserting an OCSP URI on the live bun.sh certificate - #32789
Conversation
bun.sh's reissued certificate (Google Trust Services WE1) has no OCSP responder URI in its Authority Information Access extension, so the live-host assertion in node-tls-connect.test.ts fails on every lane. Assert the CA Issuers entry instead, which is still present, and check its shape rather than just that it is defined. Exact infoAccess parsing stays covered by the fixed-fixture x509 tests.
|
Warning Review limit reached
More reviews will be available in 2 minutes and 38 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
There was a problem hiding this comment.
LGTM — straightforward test-only fix dropping a live-cert assertion that became stale when public CAs stopped emitting OCSP URIs.
Extended reasoning...
Overview
This PR touches a single test file, test/js/node/tls/node-tls-connect.test.ts, and modifies one assertion block inside the "should have peer certificate" test that connects to the live bun.sh:443 host. It drops the infoAccess["OCSP - URI"] assertion (which now fails on every CI lane because the reissued bun.sh certificate from Google Trust Services no longer carries an OCSP responder URI) and slightly strengthens the surviving CA Issuers - URI assertion from toBeDefined() to expect.arrayContaining([expect.stringMatching(/^https?:\/\//)]). The accompanying comment is updated to explain why.
Security risks
None. This is a test-only change with no production/runtime code touched. It neither weakens TLS verification nor alters any crypto logic — it simply stops asserting on a field of an externally-controlled live certificate whose contents legitimately changed.
Level of scrutiny
Low. The diff is 5 lines in a test, the rationale (CAs dropping OCSP in 2025) is factually correct and well-documented in the PR description, and the exact infoAccess parsing behavior remains covered by fixed-fixture tests elsewhere (test-tls-translate-peer-certificate.js, test-crypto-x509.js, 21274.test.ts). The replacement assertion is strictly stronger than the original toBeDefined() for the field that does still exist.
Other factors
The file is not covered by CODEOWNERS. The bug-hunting system found no issues. There are no outstanding human review comments — only bot build/rate-limit notices in the timeline. Given this is unblocking CI across all lanes with a minimal, obviously-correct adjustment to an environment-dependent assertion, it's safe to approve without further human review.
node-tls-connect.test.ts > should have peer certificateis currently failing on every CI lane, on main and on every open PR (for example https://buildkite.com/bun/bun/builds/65076):Cause
The test connects to the live
bun.sh:443and asserts fields of whatever certificate the host presents. bun.sh's certificate was reissued (Google Trust ServicesWE1, valid to Sep 2026) and its Authority Information Access extension now carries only a CA Issuers entry, with no OCSP responder URI:Public CAs (Let's Encrypt, Google Trust Services) stopped including OCSP URIs in newly issued certificates in 2025 in favor of CRLs, so the field is not coming back. The comment above the assertion already says the contents "can change over time"; this is that.
Fix
Drop the
OCSP - URIassertion. Keep theCA Issuers - URIone, strengthened fromtoBeDefined()to "a non-empty array of http(s) URIs".This loses no meaningful coverage: the exact
infoAccesskey/value parsing (including the OCSP key) is already tested hermetically against fixed fixtures intest/js/node/test/parallel/test-tls-translate-peer-certificate.js,test/js/node/test/parallel/test-crypto-x509.js, andtest/regression/issue/21274.test.ts. The live test only needs to prove the end-to-end shape.Verification
To reproduce without depending on the live host, I minted a leaf certificate matching the live one's identity and AIA (
CN=bun.sh, SANbun.sh, *.bun.sh, AIA with a CA Issuers entry and no OCSP entry) and served it onbun.sh:443through an/etc/hostsoverride.bun bd test test/js/node/tls/node-tls-connect.test.tspasses the whole file, 30 pass / 1 skip (intentional) / 0 fail.No other test asserts on the live bun.sh certificate's contents; every other
getPeerCertificate()test in the suite uses a local fixture cert.