How is each repository encrypted?
Each repository has a randomly generated symmetric content key. Purpose-specific keys derived from that content key encrypt manifests, refs, Git pack chunks, pull request metadata, review state, comments, event payloads, and keyrings. Envelopes bind version, algorithm, key identifier, purpose, repo identifier, and object identifier as authenticated data.
What are device keys and key epochs?
Each device has a signing key and a key-agreement/unwrapping key. Repo content keys are wrapped to authorized native-trusted device public keys and explicit recovery recipients. Keyring changes are signed protocol objects, and encrypted keyring snapshots record authorized devices, revoked devices, recovery policy, epoch-scoped wrapped repo keys, the keyring object epoch, current repo content-key epoch, and keyring event head.
What does account login authorize?
Registration and login use OPAQUE so the server never receives raw passwords. A successful login creates an account-bound bearer session, but that session is not a repository trust root. Browser signup creates only a convenience account; repository-capable trust starts when the native CLI or desktop path generates native signing and wrapping keys and completes native bootstrap with a fresh OPAQUE password proof.
How does the signed write model work?
Every mutating action emits a signed event: pushes, ref updates, pull request changes, comments, reviews, merge intents, keyring changes, runner registration, and job acceptance. Events include previous event identifiers so clients can detect truncation and replay against their locally pinned history. Repository creation, chunk upload, chunk deletion, and event append require native-trusted device signatures or a narrow recovery-key signature where recovery is explicitly allowed; shape-only signature checks and session tokens are not enough.
How are split views detected?
Current server-backed account, repository, runner, catalog/list, and byte-body surfaces return transparency proof bundles. Native clients verify a signed checkpoint, witness quorum, consistency from the last local transparency pin, subject-map proof, private leaf openings, inclusion proofs, and client-verifiable operation fields before exposing trusted state or advancing local pins. A server cannot keep two clients on different accepted states without causing proof failure, a witness-quorum failure, witness rollback, or permanent isolation from honest witnesses and monitors.
How are keyrings trusted?
Clients do not trust a keyring snapshot by itself. They replay signed keyring-change events from locally pinned trusted state, verify signatures against the replayed prior state, and compare the result to the candidate snapshot before using any device or recovery signer. The MVP accepts one linear keyring-change head; parallel heads and implicit multi-parent merges are rejected until merge semantics are deterministic.
What can recovery do?
Account recovery restores password access only. It can replace the OPAQUE password file, revoke sessions and pending logins, and cancel unapproved device enrollments, but it does not recover repository keys or authorize a new Git signing device. Key recovery requires a restored encrypted device backup for a still-active native device, another native-trusted device, or a personal recovery key that was already present in the repository keyring. Personal recovery keys can authorize narrow recovery actions such as adding a replacement device; they must not authorize normal repository writes.
What are the operational constraints?
- Browser-delivered JavaScript is not the preferred root of trust.
- Native CLI and desktop clients are the credible first secure clients; release signing and release/build transparency remain required release-channel hardening.
- Bring-your-own CI runners decrypt only on customer-controlled infrastructure.
- Hosted CI requires a separate trust model and is deferred.