RT-2 R0.1: F9 Chrome binary integrity (doctor, Py mirror)#3
Draft
TPEmist wants to merge 3 commits into
Draft
Conversation
Four-layer defense-in-depth for the CDP injection trust boundary
documented in docs/VAULT_THREAT_MODEL.md §2.8:
L1 — OS codesign verify + vendor identity (macOS codesign,
Linux dpkg/rpm -V, Windows Get-AuthenticodeSignature)
L2 — Static SHA-256 pin against in-repo known-good list
(pop_pay/data/chrome_known_good_sha256.json; manual PR bump)
L3 — Fork whitelist (Google / Brave / MS / Mozilla) with
--strict / default / --permissive modes
L4 — Runtime defense-in-depth (extension enumeration +
CDP port hijack sniff)
NEVER live-fetches dl.google.com or any remote feed — by design.
See VAULT_THREAT_MODEL.md §2.8 for six-reason rationale
(single trust root, availability, Chrome update lag, channel
sprawl, fork ecosystem, privacy side-channel).
Seed known-good entry: Google Chrome stable 147.0.7727.56
darwin/universal (self-verified 2026-04-21 against operator's
local install). Further platforms (linux/x64, linux/arm64,
win32/x64, win32/arm64) marked platforms_pending_seed — bumped
by PR as SHA-verified installs become available.
Deviation from original spec: macOS layer uses 'codesign --verify'
without --strict because Chrome's .app bundle contains resource-fork
metadata which --strict rejects despite the cryptographic signature
being valid. Documented in doctor_f9.py _layer1_macos and the
VAULT_THREAT_MODEL §2.8.
Ships a dependency-injection surface (F9Options.exec_fn, read_fn,
net_fn, list_extensions_fn, known_good_path) so every layer is
unit-testable without real Chrome.
Mirrors TS commit 4fe5ae8.
Refs RT-2 R0.1.
Platform-bound dispatch tests use `if platform.system() != 'X': return`
so the suite runs green on any host while each OS-specific path is still
covered on its native CI runner.
Covers:
- L1 codesign parse (Authority line extraction; Brave/MS/Mozilla teams)
- L1 dispatch mocks per platform (macOS / Linux dpkg-V / Windows Authenticode)
- L2 SHA pin (known-good match / mismatch warn / unreadable file fail)
- L3 fork whitelist (default Google+Brave pass; off-list fail;
strict Google-only; permissive any; undef vendor → fail)
- L4 extension enumeration + CDP port hijack sniff (injected)
- Orchestrator --strict escalation (L2 warn → fail)
- Data file integrity (≥1 entry, vendors_accepted_default, SHA shape)
Full suite: 247 passed / 5 skipped / 0 failed.
Mirrors TS commit 49cac5b.
Refs RT-2 R0.1.
- Usage: add --strict / --permissive / --json examples - Checks table: 10 → 15 rows (adds 5 F9 rows) - New §F9 — Chrome binary integrity: 4-layer narrative, 'never live-fetch' rationale pointer, macOS --strict deviation note, PR-bump instructions for pop_pay/data/chrome_known_good_sha256.json - KNOWN LIMITATIONS: add f9_l2_sha_pin lag note Mirrors TS commit 575f2b2. Refs RT-2 R0.1.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Python mirror of TS PR
100xPercent/pop-pay#5. Closes the CDP injection trust boundary documented indocs/VAULT_THREAT_MODEL.md§2.8 with a 4-layer Chrome binary integrity check inpop-pay doctor.Handoff spec:
workspace/handoff/pending/eng-2026-04-20-2320-rt2-f9-chrome-integrity.md(RT-2 Stage R0).Four layers
Same architecture as TS. L1 OS codesign (load-bearing) / L2 static SHA-256 pin / L3 fork whitelist (
--strict/ default /--permissive) / L4 runtime DiD.Never live-fetches
dl.google.com.Commits
6369fe7feat(doctor): F9 Chrome binary integrity (core, Py mirror)9232f75test(doctor): F9 unit tests — 24 cases (Py mirror)4b7e1d5docs(doctor): document F9 flags + checks (Py mirror)Deviation from spec
Identical to TS: macOS L1 uses
codesign --verify(not--strict) due to Chrome.appresource-fork metadata. Documented inpop_pay/doctor_f9.py::_layer1_macos.Verification
--cache-clear, 0.02s)Test plan
pytestpop-pay doctor→ 5 F9 rows presentDual-repo sync
TS primary at
100xPercent/pop-pay#5(branchrt2/r01-f9-chrome-integrity).Draft — holding for explicit founder GO before merge/bump/publish.