mosaicstack/stack
1
0
Fork 0
Code Issues 81 Pull Requests 2 Actions Packages Projects Releases 15 Wiki Activity

co-attest: SUPERSEDE v9 f320d075 — homelab 4th-round FAIL @1c34e3cb (site-startup closure, -S); v10 authorized

Browse Source
This commit is contained in:
mos-orchestrator
2026-07-18 19:16:18 -05:00
parent f320d075df
commit 3d6f556e2b
1 changed files with 40 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
docs/compaction-refresh/reviews/GATE0-PROBE3-MOS-COATTEST-v9.md
View File

@@ -103,3 +103,43 @@ assertion-FAIL / isolation-FAIL → possible Case-C → STOP + escalate to Jason
**Mos verdict: v9 full-closure + B7 + B8 byte-scope + mechanism + hygiene PASS. Co-attestation of **Mos verdict: v9 full-closure + B7 + B8 byte-scope + mechanism + hygiene PASS. Co-attestation of
record — committed.** record — committed.**
---
## ⚠️ SUPERSEDED — homelab v9 4th-round FAIL @1c34e3cb raised a stricter *startup-closure* bar
This co-attestation was **byte-clear on the v9 (env-iso + bytecode-pin) bar ONLY** and self-limited
above to *"byte-clear NOT fire-authorization; FIRE remains gated on homelab 4th-round re-verify."*
Homelab (the required third principal) returned **FAIL @1c34e3cb** (static, nothing executed), and Mos
**UPHELD** it after independently confirming the finding in-source AND empirically on host Py3.11.2 —
so the v9 byte-clear this document records is **SUPERSEDED** and does **NOT** authorize FIRE.
**Residual startup-closure hole (empirically reproduced by Mos; accepted as gate-STRENGTHENING):**
neither child carries `-S`, so CPython imports the `site` module **before** the script runs. `-s`
(launcher) suppresses only *user*-site; `-I` (broker) implies `-s -E -P` but **NOT** `-S`. Proven:
[-s -B ] no_site=0 site_imported=True ← v9 launcher: site runs
[-I -B ] no_site=0 site_imported=True ← v9 broker: -I does NOT imply -S
[-s -S -B] no_site=1 site_imported=False ← v10 launcher fix (sibling import STILL resolves)
[-I -S -B] no_site=1 site_imported=False ← v10 broker fix (additive)
System-site executable `.pth` lines + sitecustomize/usercustomize can therefore run **unpinned startup
code** before the exact launcher/broker and **outside** `closure_import_guard`, while every hash +
`reject_pinned_bytecode` + import-guard still pass — defeating hashed==executed on the full *startup*
closure (strictly wider than the module-import closure v9 cleared). A genuine fidelity hole for a
fail-closed DO-178C evidence gate.
Mos **authorized the bounded v10 repair**: add `-S` to the **launcher** (keep `-s -B`, NOT `-I`) and
to the **broker** (keep `-I -B`) — a minimal 2-line delta; no B6c regression (launcher `-s -S -B`
sibling import empirically intact; `-S` does not touch `sys.path[0]`). Added review bar **B9**
(no-site startup closure). This **rides the existing (ii)-full-closure authorization + R1 + Mos
adjudication** (deepens startup-closure isolation of an already-authorized touch, inside the fixture
temp root, no fresh Jason owner-window) and is **NOT a Case-C escalation** (static pre-fire catch, no
probe fired). A separate **FIRE-time** constraint is captured: the 3× isolation dispatch must launch
the runner under externally-enforced `python -I -S -B` (a self-reexec is too late).
**Live target = v10** (no-site harness, forthcoming). `1c34e3cb` / `e1c9a468` / this co-attestation
(`f320d075`) are **SUPERSEDED**; the prior 2-of-3 (ms-secrev-828 v9 §3 PASS + `f320d075`) does NOT
carry — all three distinct-identity principals re-verify the new v10 SHA. A fresh Mos co-attestation
will be committed on v10 byte-verify PASS. WI-3 #830 remains HELD at `f4008307`; nothing banked;
C-hatch armed (fired-rig only); NO FIRE.