Skip to content

RT-2 R0.1: F9 Chrome binary integrity (doctor, Py mirror)#3

Draft
TPEmist wants to merge 3 commits into
mainfrom
rt2/r01-f9-chrome-integrity
Draft

RT-2 R0.1: F9 Chrome binary integrity (doctor, Py mirror)#3
TPEmist wants to merge 3 commits into
mainfrom
rt2/r01-f9-chrome-integrity

Conversation

@TPEmist
Copy link
Copy Markdown
Member

@TPEmist TPEmist commented Apr 21, 2026

Summary

Python mirror of TS PR 100xPercent/pop-pay#5. Closes the CDP injection trust boundary documented in docs/VAULT_THREAT_MODEL.md §2.8 with a 4-layer Chrome binary integrity check in pop-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

  • 6369fe7 feat(doctor): F9 Chrome binary integrity (core, Py mirror)
  • 9232f75 test(doctor): F9 unit tests — 24 cases (Py mirror)
  • 4b7e1d5 docs(doctor): document F9 flags + checks (Py mirror)

Deviation from spec

Identical to TS: macOS L1 uses codesign --verify (not --strict) due to Chrome .app resource-fork metadata. Documented in pop_pay/doctor_f9.py::_layer1_macos.

Verification

  • 24/24 F9 pytest cases pass (fresh shell, --cache-clear, 0.02s)
  • 247 / 5 skipped / 0 failed on full pytest
  • End-to-end against operator's live Chrome matches TS results (default/strict/permissive L1+L2+L3 pass)

Test plan

  • CI: pytest
  • Fresh macOS: pop-pay doctor → 5 F9 rows present
  • Linux / Windows runner (once SHA seed lands)

Dual-repo sync

TS primary at 100xPercent/pop-pay#5 (branch rt2/r01-f9-chrome-integrity).

Draft — holding for explicit founder GO before merge/bump/publish.

TPEmist added 3 commits April 21, 2026 00:03
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant