docs: resequence the roadmap around soundness before ergonomics - #1
Merged
Conversation
The queue is now bugs -> finish M3 -> M5 -> M6. M5 and M6 are the two ways the boundary is currently unsound -- it stops enforcing when the daemon dies, and a static allow is hijackable by LD_PRELOAD -- so they become the must-haves, and blessing's B3/B4 defer behind them. B3 costs nothing to postpone: it *relaxes* the mint gate, and B1+B2 already ship a usable bless. B4 defers by its own logic, since a blanket "uncordoned" class widens the grant surface exactly where M5/M6 have not yet closed it. M2 and M4 stop being scheduled on their own: M6 pulls in the parts it needs (M2's `unsandboxed` predicate is M6 enforcement point 3, M4's learning machinery is how code sets get built), and the remainder is opportunistic. Also promotes the root-writable /tmp self-test probe out of the carried-over notes -- it is a live local escalation that can switch the boundary off, not a rough edge -- and closes two doc drifts: DESIGN 16 still claimed B1 only, and DESIGN 15.11 had no M6 at all despite it being the largest known hole. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Re-prioritizes the roadmap. The queue becomes bugs → finish M3 → M5 → M6, with blessing's B3/B4 deferred behind the core.
Why
M5 and M6 are the two ways the boundary is currently unsound:
exeismm->exe_file, soLD_PRELOADhijacks any staticallow. Every static allow is a confused-deputy grant.No ergonomic win is worth having on top of either, so blessing waits. B3 costs nothing to postpone — it relaxes the mint gate, and B1+B2 already ship a usable
bless. B4 defers by its own logic: a blanket "uncordoned" class is a skeleton key, and widening the grant surface before M5/M6 close those holes gets the order backwards.Changes
M2 and M4 stop being scheduled on their own — M6 pulls in the parts it needs (M2's
unsandboxedpredicate is M6 enforcement point 3; M4's learning machinery is how code sets get built), and the remainder is opportunistic.Also promotes the root-writable
/tmpself-test probe out of the carried-over notes. It is a live local escalation — a planted symlink gets root to truncate/etc/cordon/policy.toml, after which the daemon fails to compile and the boundary is off entirely — so it is item 1 in the queue, not a rough edge.Docs only; no code touched.
🤖 Generated with Claude Code