chromium: 147.0.7727.15 -> 151.0.7922.19 (clears ~63 Critical CVEs) - #420
Conversation
…CVEs) chromium-bin + chromium-headless-shell-bin were stuck at 147.0.7727.15 — ~4 Chrome majors stale — after #414 switched the source to true Chromium. Chromium 148-151 shipped Critical security fixes, so 147 is now affected by ~63 real Critical CVEs (the bulk of the fleet's Critical count in the vuln digest). Both packages bumped in lockstep across all three interlocked identifiers + both shas per arch: * browser_version 147.0.7727.15 -> 151.0.7922.19 * revision 1217 -> 1233 (Playwright browsers.json chromium entry; the arm64 leg is Playwright-gated, so 151 is the achievable target) * snapshot_position 1596534 -> 1654408 (chromiumdash branch position for 151 is 1654411; nearest available amd64 snapshot in the bucket is 1654408) * amd64 chrome-linux.zip / headless-shell.zip + arm64 playwright zips — fetched + sha256'd fresh. Done by hand: the auto-updater can't resolve chromium's 3-source scheme (Playwright browsers.json + chromiumdash + snapshot-bucket probe) and currently fails silently on it — tracked in gominimal/pkgmgr-rs (resolver + the silent- failure recording). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 10 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?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 reviews. How do review 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 refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
chromium 151's amd64 chrome binary hard-links libXtst.so.6, which no package in the tree provided — so the build was green but chromium-bin's standalone check failed at load time (`error while loading shared libraries: libXtst.so.6`), exit 127 on even `chromium --version`. readelf of the amd64 151 chrome shows 33 DT_NEEDED libs; every one is covered by chromium-bin's existing runtime_deps EXCEPT libXtst.so.6 (the only addition over the 147 build). chrome doesn't link libXi directly — libXtst does (Requires.private: x11 xext xi), so libxtst pulls it in transitively. One dep closes the closure; no other gaps. - packages/libxi (1.8.3): X11 Input ext lib; runtime deps libx11/libxext/ libxfixes/glibc (from libXi's Requires.private: x11 xext xfixes). - packages/libxtst (1.2.5): X11 Testing ext lib (libXtst.so.6); runtime deps libx11/libxext/libxi/glibc. - chromium-bin: add libxtst to runtime_deps (pulls libxi transitively). Both libs are standard autotools X.org packages modeled on libxext, sourced from gs://minimal-staging-archives (tarballs mirrored). Built locally (minimal package --rebuild) — real trees with libXi.so.6 / libXtst.so.6; libXtst.so.6 DT_NEEDED confirms the libXi link. headless-shell passed its check (its binary doesn't link libXtst), so it's left unchanged. See #421.
The chrome-headless-shell binary hard-links libXtst.so.6 too (the build check caught it — smoketest exit 127 on the amd64 headless-shell). The prior commit added libxtst only to chromium-bin on the assumption headless-shell didn't need it (it wasn't in the first failure log, but that was a stale/cached build). Add libxtst to its runtime_deps as well — same transitive libxi pull.
Updates chromium-bin + chromium-headless-shell-bin from 147.0.7727.15 →
151.0.7922.19, clearing ~63 real Critical Chromium CVEs (the bulk of the
current vuln-digest Critical count).
Why they were stale
After #414 switched the source to true Chromium, both packages sat at
147.0.7727.15 — ~4 Chrome majors behind. On June 30, 147 was the latest (0
known CVEs); since then 148–151 shipped with Critical fixes, so 147 is now below
every one of their fix versions. The scan is correct — this is real, not a false
positive.
What changed (both packages, in lockstep)
chromium here uses three interlocked version identifiers + two shas per arch,
all hand-derived:
browser_versionrevisionsnapshot_positionFour binaries fetched +
sha256'd fresh:chrome-linux.zip+headless-shell.zip(amd64 snapshot 1654408), and the arm64 Playwright
chromium/headless-shellbuilds at revision 1233.
Static checks green on both (
parse/fmt/output-naming/disallowed-patterns);the build-bot verifies extraction + the
chromium --versionsmoketest.Why by hand
The auto-updater can't resolve chromium's 3-source scheme (Playwright
browsers.json + chromiumdash + snapshot-bucket probe) and currently fails
silently on it (your "Create PR" click produced no PR and no error). Both the
resolver and the silent-failure recording are being tracked + fixed in
gominimal/pkgmgr-rs.
🤖 Generated with Claude Code