4 Commits

Include renames

Author	SHA1	Message	Date
Robert Allan JamesandClaude Sonnet 5	6302dcb50e	FABRIC-3.7.md: record Phase 8 v3 closure (in-system block-copy defense) ... Distinguishes it clearly from the still-accepted "cloned outside StarshipOS entirely" limitation this document already settled -- Phase 8 v3 closes a narrower, different threat: cloning block content using StarshipOS's own console primitives, now refused by MOVE/CMOVE/CMOVE>/ RELOCATE-BLOCK for cross-device copies. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-23 04:45:06 -04:00
Robert Allan JamesandClaude Sonnet 5	b7d9ed5425	FABRIC-3.7.md: settle drive-cloning defense as rejected, not undesigned ... Captain Bob rejected a PIN/passphrase second factor firmly and directly after it was built and live-tested on all three architectures: "nothing like a pin or a password or secret code or any bullshit... Everybody has secrets. There's only the drive." All PIN-related code (KDF, XOR keystream seed encryption, no-echo input, MINT/WIREBIND prompts, user_identity_seed_t v3 format) was reverted before commit -- none of it ever landed in git history. This project's identity model has no knowledge factor, by design: physical possession of the thumbdrive is the entire credential. A byte-for-byte clone being equivalent to the real drive is the accepted model, not a gap needing a fix. Recorded here so future work doesn't default back to a PIN/password approach. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-23 03:42:38 -04:00
Robert Allan JamesandClaude Sonnet 5	81049da268	Correct FABRIC-3.7.md: the original elevation-entrypoint bug diagnosis was wrong ... Found while starting Part A's implementation, before any code was written against the original design: reading the actual deleted SEND-ELEVATE-REQUEST source (git show 3e201c8^:capsules/common/messaging.4th, block 5040) shows it copied the target word's name as literal character bytes into a scratch buffer, building "S" <name-text>" <pk0> <pk1> <pk2> <pk3> ELEVATE-GRANT" entirely in the sending VM's own memory, then sent that finished string -- never a raw address -- to Hera. waddr/wu never crossed the VM boundary as numbers anywhere in this flow. The original write-up reasoned from ELEVATE-GRANT's own signature alone, without first reading how the caller actually built its message. Corrected in place, wrong original text kept struck-through for traceability rather than deleted, per this series' own convention. Net effect: Part A (the buffer/message redesign) is not needed -- the original mechanism was already safe. Part B (capsules/zuse.4th, already committed and three-arch verified this session, 089ab21) stands on its own, unaffected. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 23:03:47 -04:00
Robert Allan JamesandClaude Sonnet 5	2008c4596a	Add FABRIC-3.7.md: Phase 8 PKI elevation-entrypoint design, fixes a real pointer-confusion hole ... New document, not a reopening of the closed FABRIC-3.5.md/FABRIC-3.6.md -- successor for exactly one topic, per those documents' own close discipline. Records a security defect found by inspection while auditing Phase 4's collateral damage to ELEVATE-GRANT: the old SEND-ELEVATE-REQUEST mechanism passed a raw address (waddr/wu) computed in the sending VM's own memory space across to Hera, which dereferences it in Hera's own space -- per-VM vaddr_t means those are never the same address space. Whoever controls waddr controls what dictionary entry NAME>XT resolves to on Hera, independent of the caller's actual pubkey/eligibility. Design fix: never cross an address, only ever cross bytes -- generalizes this session's own payload-aliasing fix (SkHermesMessage.payload_buf) one level up. Send the target word's name as inline payload bytes, copy them into a fixed kernel-owned buffer already in Hera's own memory on receipt, and hand vm_interpret() only kernel-controlled integer literals referencing that buffer. ELEVATE-GRANT itself is unchanged -- policy logic stays in FORTH, per ACL.4th's own rule. No code written or authorized by this document. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 21:44:06 -04:00