From 9ee029e7d4da082dcf302291d9235f1e6b2b0bd1 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Fri, 28 Aug 2026 16:57:45 -0400 Subject: [PATCH] =?UTF-8?q?FABRIC-3.md:=20close=20WIREBIND,=20the=20real?= =?UTF-8?q?=20attach=20call=20site=20(=C2=A7F.23)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_019ZGkimpfyh63EZyRkNbkPD --- FABRIC-3.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/FABRIC-3.md b/FABRIC-3.md index 1373857..3a93d6e 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -2960,3 +2960,45 @@ async-over-synchronous decision, but a real UX question for later if it proves t practice; whether a console VM should get a default subscription to `COMMON-CH` (skipped in v1 — direct 1:1 console↔user traffic doesn't need it, and it would require resolving an index in Hermes's own routing table for a VM that doesn't have one yet). + +### F.23 — `WIREBIND`: the real attach call site, no manual steps + +Every phase closure from §F.18 through §F.22 pointed at the same gap: `RUNCAP-TEST` and +`PAIR-TEST` were diagnostic scaffolding, exercising `CERTVERIFY`/`RUNCAP`/the console pair by +hand, not a real attach flow. `WIREBIND` (§F.5, originally a breadcrumb) closes it — and +turned out to be assembly, not new design: every hard decision it needed was already made in +earlier scoping (§F.9's ACL-comparison rules, §F.7's cert trust model), and `CERTVERIFY`'s own +orchestration already existed (`vm_identity_from_cert()`, Phase A/B — verify-signature + +check-serial + extract-owner-pubkey in one call) — it had just never been wired to a live +attach. + +**The flow** (`capsule_wirebind_try_attach()`, called from `sk_repl_idle()` alongside +`capsule_zuse_boot_try_attach()`, same `HOMEBLOCKS_SIG_OK` hook): `sig->cert_offset == 0` +means this is Zuse's own genesis-mode drive (no cert region, §F.21) — that's already the other +function's job, skip. Otherwise, with Zuse already authenticated this boot (nothing to verify +a regular cert against otherwise — a real precondition, not an oversight), read the cert +devblock(s) and call `vm_identity_from_cert()` against `mama_vm`'s own `zuse_cert_pubkey` and +the drive's `drive_uuid`. On success: read the drive's own `user_identity_seed_t` for its +`username`, birth a console VM + `RUNCAP`-born user VM pair (idempotent — no-ops if that +username is already live this session), install the verified `VMIdentity` onto the user VM, +register the `"~user"` pairing `sk_repl_dispatch_line()` (§F.22) looks for. +Deliberately does **not** auto-`USE` the new console — that stays an explicit, `BINDSTEP`-gated +step (§F.9), not something a bare attach should trigger silently. + +**Verified end-to-end, live, including a genuine negative case — not just the happy path:** +attached `disk/user1.img` (its cert signed by a *different*, earlier-session Zuse instance — +Zuse's own keypair is freshly random every genesis mint) and got `"WIREBIND: cert verification +FAILED -- drive refused"` — real proof the check actually verifies against the *live* session's +own root, not a rubber stamp. Minted a fresh identity with *this* boot's own Zuse +(`S" Sam Sample" S" SamS" ... MINT`), reattached, and got `"WIREBIND: SamS attached and ready +-- USE it to begin"` printed with **zero manual commands** — no `PAIR-TEST`, no `RUNCAP-TEST`. +Followed by a clean `USE SamS` and a working async `WELCOME` relay end to end, identical in +shape to §F.22's own manual-pairing proof. Clean 3-architecture regression: Hermes/Artemis +both birth live, no unexpected ACL denials or `UNKNOWN WORD`. Commit `6fc0ee3`. + +**Still open:** `BINDSTEP` itself (§F.9) — `USE` is still unguarded; `WIREBIND` installs a real +`VMIdentity` onto the user VM but nothing re-verifies it on `USE` yet, so the ACL-gated +re-attach check that closes this whole identity arc is the one piece left. The fence-marker +persistence gap (§F.21) still means Zuse can't re-authenticate across a real reboot in this +QEMU environment — worked around for this verification the same way, via a fresh genesis mint +within the same boot session, not fixed here.