Watch
1
0
Fork
You've already forked SouveraineOS
0
SouveraineOS/docs/souveraine-components
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Fimeg fc0ee4e1ed components: add Souveraine Rebuilt tiered inventory; update queue
INVENTORY.md seeds the eventual project reorg: authority substrate,
agent substrate, boot/session surfaces, rebuilt apps, platform. Queue
doc: lockscreen recreation done, three new named wants.
2026-07-17 07:12:15 -04:00
..
audit-status.md souveraine-components: per-binary docs + RedFlag-shaped audit tracker 2026-07-16 21:48:13 -04:00
INVENTORY.md components: add Souveraine Rebuilt tiered inventory; update queue 2026-07-17 07:12:15 -04:00
machined.md souveraine-components: per-binary docs + RedFlag-shaped audit tracker 2026-07-16 21:48:13 -04:00
README.md components: add Souveraine Rebuilt tiered inventory; update queue 2026-07-17 07:12:15 -04:00
secrets.md souveraine-components: per-binary docs + RedFlag-shaped audit tracker 2026-07-16 21:48:13 -04:00
sessiond.md souveraine-components: per-binary docs + RedFlag-shaped audit tracker 2026-07-16 21:48:13 -04:00

Souveraine components — substrate binaries

One page per secure Rust binary in the Souveraine substrate. These are the system- and user-tier daemons that hold authority the shell and agents never touch directly: machine identity, the secret service, and the session authority. Each page names what the binary owns, what crosses its boundary, and the open gaps before it reaches the RedFlag security bar.

The family is small on purpose. Adding a binary here means it holds authority no other component should hold — signing keys, unlock verbs, secret material. If a daemon does not meet that bar, it is not a component, it is a library.

The full "Souveraine Rebuilt" inventory — agent substrate, boot/session surfaces, rebuilt applications, platform — lives in INVENTORY.md, organized in tiers. This page stays authority-only.

Members

Binary Tier Owns Page
souveraine-machined system machine Ed25519 seed machined.md
souveraine-secrets user (session) org.freedesktop.secrets backed by the seed lineage secrets.md
souveraine-sessiond user (session) ext-session-lock; the unlock verb sessiond.md

The security bar these are built toward

Every component is on a path to the same posture RedFlag already embodies (SESSION-AUTHORITY-DOCTRINE §10/§11, SECURITY-AUDIT P1P7):

  • Binaries verify each other. A component that asks another for an authority action (sign, unlock, release a secret) must present an attestation the target checks — a hash or capability token resolved over a closure, not a name in a config file.
  • Capability tokens, not installation. Authority rides the federated seed identity (P7), not "this binary is in /usr/local/bin." The kernel stops are defense-in-depth, not the gate (RedFlag constraint #5).
  • One authority. Session authority and binary authority are the same authority (§11). sessiond verifies capability tokens on the things that ask it to unlock or step up; machined signs them; secrets releases against them.
  • Seeds are preconditions. No daemon creates identity. A missing seed fails loudly; generation is a deliberate, guarded CLI action.

Where a component has not yet reached that bar, the gap is recorded in its page under Audit gaps and rolled up in audit-status.md. The intent is that the audit doc is the live tracker: when a gap closes, the line moves there, and the component page's Audit gaps section is updated to match.