From d42a81961cdd9e171203be305c3d175ab146b415 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Sat, 22 Aug 2026 07:21:42 -0400 Subject: [PATCH] FABRIC-2.md Section U fourth addendum: user-role tiers, and snakeoil cert resolves Milestone 7's bootstrapping question for dev/test builds Three distinct user-role tiers clarified (builder+dev, SDK-only dev, no-SDK user) -- refines the trust-tier question beyond a simple core/ contrib boundary. More importantly: a snakeoil cert embedded directly into each build (not loaded as a capsule, not verified against an external CA at boot) is the actual answer to the CA-bootstrapping problem Section X's Milestone 7 punch-list surfaced, at least for dev/ test builds -- trust is established at build time, sidestepping the runtime chicken-and-egg entirely for that case. Two paths into a build confirmed: snakeoil-signed, or code review + inclusion in the source repo -- the latter likely makes at least one of Milestone 8's four spitballed trust-tier directions (signature-authority tiers) redundant, worth revisiting before picking one. Co-Authored-By: Claude Sonnet 5 --- FABRIC-2.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/FABRIC-2.md b/FABRIC-2.md index 918b961..4f2b5d4 100644 --- a/FABRIC-2.md +++ b/FABRIC-2.md @@ -2738,6 +2738,38 @@ virtio-blk's build-out for comparison. QEMU-vs-real-hardware conditional rather than uniformly strict everywhere, which is plausibly *why* item 15's assumption was worth stating up front. +**Fourth addendum — user-role tiers, and the snakeoil-cert answer to Milestone 7's +bootstrapping question, 2026-08-22:** + +19. **Three distinct user-role tiers, not just "core" vs. "contrib."** (a) Builder+dev — + builds the kernel/toolchain itself and develops capsules (Captain Bob's own role). (b) + Dev — uses only the FORTH SDK (`capsules/sdk.4th`) to author capsules, doesn't build the + kernel. (c) A user with no SDK at all — presumably runs pre-built capsules only, no + authoring capability. This refines the trust-tier question from item 17/spitball above: + it's not a single core/contrib boundary, it's at least three capability levels. +20. **Snakeoil cert, embedded per-build — this resolves Milestone 7's open bootstrapping + question, at least for dev/test builds.** Every capsule and named blob gets signed with a + "snakeoil" cert (the standard term for a self-signed, non-production dev/test + certificate) that is itself embedded directly into each build — not loaded as a capsule + at runtime, not verified against an external CA at boot, part of the trusted build + process itself. This sidesteps the "how does the CA public key get into the kernel + without being just another unverifiable capsule" problem Milestone 7 raised, for the + dev/test case specifically: there's no runtime verification-against-external-root step at + all for snakeoil-signed content, because trust is established at build time, not boot + time. The real external-CA chain from Section U items 10-14 presumably still applies for + genuinely distributed/production builds; snakeoil is the dev/test answer, not a + replacement for it. +21. **Two paths into a build, nothing else.** A capsule or named blob makes it into a build + only by (a) being signed with the build's own snakeoil cert, or (b) going through code + review and inclusion in either the build or the single source repo. This substantially + simplifies Milestone 8's still-open trust-tier decision (item 17's spitballed + directions) — "in the reviewed source repo" is itself the trust signal for + production-track content, rather than needing a separate signature-authority-tier scheme + layered on top. Worth revisiting Milestone 8's punch-list items against this before + picking one of the four originally-spitballed directions; at least one of them + (signature-authority tiers) may now be redundant with "repo inclusion already is the + review gate." + --- ## V. Gap analysis — Artemis home-blocks/thumbdrive/PKI subsystem, 2026-08-22