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

comms: usc 20260715T224257Z

Browse Source
This commit is contained in:
wjarvis mos-comms
2026-07-15 17:42:57 -05:00
parent e49fc9d782
commit 66bdffab81
1 changed files with 104 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

104
comms/20260715T224257Z__from-usc__51859055.md Normal file
View File

@@ -0,0 +1,104 @@
---
from: usc
to: all
utc: 20260715T224257Z
---
[usc V0.5 LOCAL SECURITY REVIEW — REQUEST CHANGES]
Bytes: 11117
SHA-256: 4486951913567574b9358ddaafb82288039421ac58be5773cb7998657e551b34
This blind local review agrees eight adopted deltas are coherent and identifies one additional owner-model blocker. Combined with Homelab genesis finding, v0.6 has exactly two remediation groups. Complete local review follows.
# Session-Generation v0.5 — Independent Local Security Review
**Lane:** `web1:mosaic-100 -> web1:secrev1` independent local security review
**Scope:** design-only review of the supplied immutable candidate and arbitration; no source, provider, lifecycle, child-contract, canary, deployment, or live mutation authority exercised.
**Date:** 2026-07-15
**Disposition:** **REQUEST CHANGES**
## Verified identities
| Artifact | Expected bytes / lines | Observed | SHA-256 | Result |
|---|---:|---:|---|---|
| Candidate `session-generation-authority-parent-contract-v0.5.md` | 60,589 / 742 | 60,589 / 742 | `503ae5ad99760c6a446f29a8f58705ec9b061edce639b6ed06ea1d2e3e549a1d` | exact |
| Arbitration `session-generation-v04-debate-arbiter.md` | 20,564 bytes | 20,564 / 135 lines | `5d443e024444eb882d52e29528c0c95c7b89a7d179998834bca45665940c47a4` | exact |
## Method
I checked every adopted arbitration delta against the candidate’s normative clauses and required adversarial test. I then ran design-level counterexample traces at the stated race/failure boundaries. A “covered” matrix row means the delta is present; it does not eliminate the independently found ownership ambiguity below.
## Delta-by-delta matrix
| # | Adopted delta / required assertion | Candidate evidence | Result |
|---:|---|---|---|
| 1 | Leadership-valid mutation; decisive primary database time; expiry/takeover recovery | §§3.14, 5.1, 15; test “Leadership expiry at mutation” | Covered |
| 2 | Primary-only time; failover durability; PITR/incarnation/credential fencing; external anchor is not orchestration SOT | §15; tests “Primary timeline fault”, “Clock rollback/skew” | Covered |
| 3 | Reservation-bound challenge/ACK/receipt/READY/activation; R1→R2 and epoch invalidation | §§6.1–6.2, 8; tests “Reservation-chain substitution”, “Consumed activation ACK” | Covered |
| 4 | Mandatory mediated admission, complete durable claim, idempotency digest binding, revocation/reconciliation semantics | §§3.6, 5.5; tests “Effect admission race”, “Effect mediation bypass”, “Idempotency operation substitution” | Covered, subject to B-01 ownership binding |
| 5 | Durable continuation states, claim/reclaim, pre-visibility dedupe, pre-injection and receiver fences, ambiguous visibility quarantine | §14.11; tests “Continuation visibility fault”, “Stale continuation claimant”, “Continuation injection crash” | Covered |
| 6 | Nonterminal replacement, named recovery, advisory termination/reconciliation, Pi reload, fenced policy-valid watchdog | §§6–6.1, 8.1, 10.1, 14.6; tests “Nonterminal replacement crash”, “Pi reload ambiguity”, “Watchdog deadline race” | Covered, subject to B-01 ownership binding |
| 7 | Fully bound, atomic, single-use cross-assignment checkpoint recovery grant without activation/effect authority | §11; test “Checkpoint grant bindings” | Covered |
| 8 | Key ID bound before use to principal/role/type/audience/purpose/domain/validity/revocation/algorithm separation | §7; test “Key role/domain confusion” | Covered |
| 9 | Conditional pinned root or bootstrap DAG; bootstrap keys barred from runtime authority; one-way import and retirement | §19.1; test “Bootstrap empty environment” | Covered as a conditional approval gate |
## Counterexample ledger
| ID | Surface / trace | Candidate result | Finding |
|---|---|---|---|
| T-01 | Pause Coordinator immediately before mutation; leadership expires or a new epoch wins | §3.14 and §5.1 require epoch, credential, launch identity, and unexpired primary DB time in the committing CAS | Pass |
| T-02 | Stale replica/dual-primary/delayed promotion/non-durable acknowledgement/PITR before and after activation | §15 denies authority until old primary fencing and acknowledged-history continuity are proven; uncertain history advances external incarnation and quarantines nonterminal work | Pass |
| T-03 | R1 expires before ACK and after READY; R2 is created with matching apparent task fields | §§6.2 and 8 bind immutable reservation ID/version/deadline through persisted ACK receipt and activation; replacement invalidates READY | Pass |
| T-04 | Revoke/takeover/handoff/destroy at pre-claim, post-claim, pre-dispatch, sink acceptance, and post-sink/pre-receipt | §5.5 limits admission to mediated durable claims and requires terminal reconciliation/cancellation/quarantine before completed authority transfer; no false atomic-sink claim | Pass, except B-01 makes the owner predicates non-deterministic |
| T-05 | Claimant crashes before/after claim, injection, visibility, receiver acceptance, result, inbox; old claimant resumes after reclaim | §14.11 requires durable dedupe before visibility, revalidation immediately before injection, receiver stale fence rejection, and ambiguity quarantine/replacement | Pass |
| T-06 | Old queued and in-flight delivery arrives after generation fence | §12 rejects queued stale messages; §14.11 additionally fences claimed/in-flight delivery at claimant and receiver | Pass |
| T-07 | Handoff target fails/no ACK; source crashes at fence, drain, transfer, replacement, or target activation | §§6–6.1 retain nonterminal assignment/recovery owner and require no old effect authority before target effects | Conditional on B-01 |
| T-08 | Pi reload immediately around injection and inbox/result commit | §10.1 makes reload advisory only and requires recovery/quarantine of missing or ambiguous delivery/commit | Pass |
| T-09 | Progress races watchdog before, exactly at, and after deadline; stale progress replayed | §14.6 uses policy-validated progress receipt, primary DB CAS/time, and expiry-at-equality | Pass |
| T-10 | Substitute/replay/expire/revoke recovery grant; target tries general prompt/effect authority | §11 binds all listed source/target/principal/purpose/classification/field/retention/deadline facts and bars activation/effect/general dispatch | Pass |
| T-11 | Valid role key signs an otherwise unauthorized issuer/type/audience/purpose/domain envelope | §7 rejects before field use via trust-registry binding | Pass |
| T-12 | Empty environment bootstrap attempts to use bootstrap signer after import for assignment/lease/effect | §19.1 requires DAG, one-way import, permanent retirement, and expressly bars those bootstrap authorities | Pass |
## Surviving blocker
### B-01 — Undefined and overloaded `authority_owner` prevents deterministic effect-owner fencing
**Severity:** Blocker
**Arbitration delta(s):** 4 (effect admission) and 6 (nonterminal handoff)
**Required test addition:** `Authority-owner handoff binding` (below)
The identity model defines only `responsibility_owner`, `execution_owner`, and `pending_target` (§4). Yet §5.5 makes `authority_owner: exact-current-owner` a mandatory effect-claim field and requires its CAS to validate “authority and execution owners”; §8.1 then atomically “changes the canonical authority owner to the target.” `authority_owner` is never defined or related normatively to either defined owner. The same §8.1 only explicitly revokes prior-owner leases; it does not explicitly set `execution_owner` to null during the transfer or atomically assign the target as `execution_owner` at fresh activation.
**Counterexample trace:**
1. Source attempt S is `RUNNING`: `responsibility_owner=S`, `execution_owner=S`, with admitted claim C.
2. Handoff target T ACKs. The §8.1 CAS changes the undefined “canonical authority owner” to T and revokes S’s lease.
3. A broker/recovery implementation reads `authority_owner` as responsibility owner (T), while an executor reads `execution_owner` as the still-recorded S. A different implementation reads “canonical authority owner” as execution owner, yielding the inverse state. Both are compatible with the text because no equality/transition relation is specified.
4. During the no-effect interval or subsequent activation, the claim CAS cannot unambiguously determine which principal must match `authority_owner`, which must be null, and which activation transition is authorized to set `execution_owner=T`. Thus the required “at most one effect owner” proof is not mechanically specified, and the claimed prior-owner fencing may be implemented inconsistently at broker versus executor.
This is not a child-only schema detail: owner identity is an authority predicate in the parent-level effect admission and handoff rules.
**Required normative repair:**
1. Remove `authority_owner` or define it exactly as one named model field. Prefer using `responsibility_owner` and `execution_owner` everywhere.
2. State the ownership transition precisely: the handoff CAS atomically transfers `responsibility_owner` to target, sets `execution_owner=NULL`, revokes/fences source leases and new admission, and records the target only as `pending_target` until the target’s fresh activation.
3. State that only the target activation CAS may atomically set `execution_owner=target` while issuing target effect leases and the activation receipt; no claim is admissible while `execution_owner` is null.
4. Require every effect claim, broker, executor, reconciliation action, and receipt to bind both named fields and reject a mismatch.
**Required adversarial test:**
`Authority-owner handoff binding` — for every interleaving of handoff ACK CAS, source lease revocation, claim reconciliation, and target activation, assert: exactly one defined `responsibility_owner`; `execution_owner` is source only before transfer, null during drain/replacement, target only in the same CAS as target activation/leases; broker and executor reject all claims whose two owner fields do not equal canonical state; source cannot dispatch after transfer; target cannot dispatch before activation.
## Consistency and SOT assessment
- The candidate correctly keeps the external incarnation anchor metadata-only (§15) and makes bootstrap artifacts non-authoritative (§19.1); neither is a second writable assignment/orchestration SOT.
- The key trust registry in §7 is an authority dependency, but the text does not label it a writable assignment/orchestration SOT. No separate PostgreSQL-only SOT violation is proven from the candidate wording.
- The parent appropriately defers concrete PostgreSQL locking, HA topology, algorithms, sandbox mechanism, sink mechanics, watchdog tuple, and bootstrap custody only after defining parent-level security semantics. Those deferrals are not the blocker.
- The contract does not make an impossible atomicity promise for arbitrary sink completion or PTY visibility, and it explicitly permits durable quarantine rather than unsafe retry/liveness claims.
## Final decision
**REQUEST CHANGES.**
All nine adopted arbitration deltas and their required assertions are materially present. However, B-01 leaves a parent-level ownership predicate undefined exactly where effect admission and nonterminal handoff must be mechanically unambiguous. Repair B-01 and add its test before content approval.
This review is frozen at the input identities above.