From 33493e23c1cb87ad877bcbb1e003505103a42086 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Fri, 28 Aug 2026 15:33:33 -0400 Subject: [PATCH] =?UTF-8?q?FABRIC-3.md:=20capture=20general-purpose=20cons?= =?UTF-8?q?ole=20vision=20+=20close=20MINT=20profile=20fields=20(=C2=A7F.2?= =?UTF-8?q?0)?= 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 | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/FABRIC-3.md b/FABRIC-3.md index 670399f..6597ae3 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -2750,3 +2750,60 @@ prompt for a reattach. meant to survive into that flow unchanged. With `CERTVERIFY`, `RUNCAP`, and `MINT` all real and composing, `WIREBIND` is now the last piece standing between this arc and D.7's original message-only birth vision. + +### F.20 — general-purpose console vision + MINT profile fields (2026-08-28) + +New direction, stated directly: get rid of the emergency CLI entirely (today's unauthenticated +`ok>` bypass) in favor of a general-purpose console that attaches to *any* VM an identity has +ACL access to — Tripod legs included, not just user-spawned VMs — via **two** complementary +mechanisms, not alternatives: `BINDSTEP`'s already-scoped ACL-gated `USE` redirect (cheap, +direct, the admin/debug path) *and* a genuinely new console-VM + user-VM pair, talking over the +real messaging layer (Phase C) rather than direct dispatch — the actual next step toward the +message-passing-OS vision, since every line becomes a message instead of a C-level redirect. +Zuse stays "no different than any other VM" except her ACLs (`VM_IDENTITY_CAP_ALL`); ACLs are +inherited (mechanism not yet designed — real open item once the console-VM pair is scoped). + +**Real gap surfaced immediately, not assumed away:** removing the emergency CLI removes the +*only* currently-unauthenticated path into a session — but Zuse's own identity today comes from +an unauthenticated first-boot self-mint (`kernel_main.c`'s `virtio_rng` → `ed25519_keygen` → +`vm_zuse_cert_install()` → `zuse_cert_devblock_t` block-fence write). Decided: **Zuse becomes +thumbdrive-resident too, minted through this same `MINT` flow, not system-resident via the +block-fence.** The block-fence flow's own retirement is scoped, not yet built — that's the +next concrete step once the console-VM pair work reaches it. + +**Immediate, concrete, scoped ask actioned first:** `MINT` needed to carry a real human profile +— full name, username, email, phone (email/phone nullable) — before minting real test +identities makes sense. Extended `user_identity_seed_t` to v2 with fixed `full_name`/ +`username`/`email`/`phone` fields (plenty of unused pad space already there — 4016 bytes). +**Deliberately NOT encoded into the DER cert's Subject field** — that would mean a real X.509 +`RDNSequence` (`commonName`/`emailAddress` OIDs, `PrintableString`/`UTF8String` tagging), well +past `x509_ed25519.h`'s own stated "deliberately not a general ASN.1/X.509 [builder]" scope. +This data isn't security-relevant the way pubkey/serial are (the only two fields `CERTVERIFY`/ +`BINDSTEP` actually check) — it travels alongside the keypair in the plain identity record +instead. `capsule_mint_identity()` and the `MINT` word both grew to take it (`MINT`'s stack +signature is now 4 string pairs, `( fname-c fname-u uname-c uname-u email-c email-u phone-c +phone-u -- ok? )`). + +**Apollo test rig:** three disk fixtures for this next phase of live testing — `disk/zuse.img` +(pre-existing from Phase 8 kickoff, blank, exactly the intended Zuse-thumbdrive target), +`disk/user1.img` (new, 64MB, a regular-user thumbdrive), `disk/apollo-ssd.img` (new, 30MB, +matching Artemis's own size convention, deliberately separate from the actively-used +`disk/artemis.img` so this phase starts from a clean slate). + +**Verified live in QEMU:** minted two real identities with real data — Zuse (`full_name` +"Konrad Suse", `username` "Zuse", `zuse@pantheon.org`, `+18885555555`) onto `disk/zuse.img`, +and a regular user (`full_name` "Captain Bob", `username` "CaptBob", +`capt.bob@pantheon.org`, `+18885555556`) onto `disk/user1.img`. Both minted only one at a time +(the single-USB-device constraint §F.8 already noted). Read the raw devblock bytes back off +both images directly afterward and confirmed every field byte-exact at its correct struct +offset (record starts at devblock 3 = byte 12288; `full_name` at +72, `username` at +136, +`email` at +168, `phone` at +232). Clean 3-architecture regression boot confirms no side +effects. Commit `6fd8792`. + +**Not yet done, deliberately:** `disk/zuse.img`/`disk/user1.img` now hold real, live-minted +keypairs — not committed alongside the code this pass, pending a decision on whether these +become tracked fixtures or stay local-only. The bigger swap this section opened (Zuse's +first-boot mint routed through `MINT` onto a thumbdrive, block-fence flow retired, emergency +CLI removed) is scoped in direction but not yet traced against the actual boot-sequence code +the way `RUNCAP`/`MINT` themselves were before being built (§F.18/§F.19's own discipline) — +that trace-first pass is the next step, not this one.