Trust and Threat Model

This page is the authoritative current-state reference for Prikk’s trust and threat model. It describes the implementation on main as of 2026-08-18 (released through 0.22.1) and is grounded in the code, released RFCs, and implementation status records listed in the anchor table at the foot of the page. Refreshed 2026-08-18 after DC-53 completed; before that refresh this page still described 0.16.0 and stated several AUTHOR claims that DC-53 had falsified.

Core Caveats

• Prikk is early implementation software and is not a production Git replacement.
• .prikk/ is Prikk’s native repository format and is not Git-compatible storage.
• Ref pointers are mutable, not roots of trust.
• Maintainer trust is repository-local with the current minimal required = 1 policy.
• verify is not a global trust proof.
• MAINTAINER key revocation exists (prikk trust maintainer remove); there is no key rotation, hardware signing, remote trust, sync trust, or stable migration policy yet, and no AUTHOR-identity revocation. For AUTHOR keys specifically (DC-53 Stage 2): one key_id is permanently bound to the first public key ever recorded for it in a given repository; attempting to sign under the same key_id with a different key — whether from a genuine rotation attempt or an impersonation attempt — is refused identically, and is indistinguishable as the reason for the refusal.
• Durability and recovery claims are supported by current unit and integration tests, not by a completed crash-matrix or fuzzing campaign.
• Repository mutation is exercised by project gates on Linux, macOS, and Windows (DC-87 Stage 2). Windows’ anchoring guarantee is weaker than Linux/macOS in one stated way — see platform support for the exact gap and which of the nine durability guarantees are held, weaker, or documented no-ops there. Read-only commands are CI-gated on macOS and Windows too — see platform support.

Changes that alter trust, threat, verification, signature, key-management, durability, platform-support, or production-readiness claims require architect review or accepted RFC/DC coverage. The local persistence and crash-recovery boundary is covered by the durability and crash recovery reference. The current verify / doctor diagnostic catalog is covered by the integrity and recovery diagnostics reference. Current operator setup for environment key input and repository-local maintainer trust is covered by the security and signing setup guide. Physical trust-store paths and other .prikk/ authority boundaries are covered by the repository layout and authority reference. Repository path validation and worktree write-safety limits are covered by the path and worktree safety reference.

Trust Roots and Roles

Current signing uses role-bound Ed25519 signatures. The signature preimage binds the algorithm, object type, object id, signer role, and key id. Signer roles include AUTHOR and MAINTAINER. Ed25519 signing and strict verification live in prikk-crypto; trust stores, key persistence, rotation, revocation, and policy are outside that crate.

AUTHOR signatures identify the key used by the authoring path for Patch envelopes. Production commit and rollback-draft authoring use real Ed25519 AUTHOR signatures. Since DC-53 (2026-08-18) Prikk does maintain a repository-local AUTHOR key-material store and verify checks every reachable Patch’s AUTHOR signature against it. Prikk still implements no AUTHOR revocation, rotation, expiration, or identity policy.

What AUTHOR key material proves, stated precisely (DC-53 Stage 2). A repository records each key_id’s public key the first time it observes a Patch signed under that name — trust-on-first-use, and that first observation is not itself verified against anything. Every subsequent appearance of the same key_id is checked against the key recorded at first contact, and one key_id is permanently bound to one public key for the life of that repository. What this proves is “the same key_id has always signed under this name here” — not “this author’s claimed identity is genuine.” A reader must be able to tell “prikk verified this author” apart from “prikk verified this author is the same one as last time”, because only the second is true.

When AUTHOR key material travels in a bundle (prikk bundle export/import, DC-53 Stage 2), the same limit applies with one further step: a transported key is supplied by the sender. A signature that verifies against a key which arrived in the same bundle proves only that the two are internally consistent — an attacker who re-signs a Patch with their own key and ships that key in the bundle produces a bundle that verifies perfectly. Import records transported material under the same first-contact rule as local material; it performs no additional check of who actually holds the key. Transport does not weaken the maintainer signature’s own role in DC-78’s exchange claim — a receiver still relies on that signature for the decision to include imported patches at all; AUTHOR verification adds continuity of authorship on top of it, and does not replace it.

MAINTAINER signatures identify publication objects. Seal uses real role-bound Ed25519 MAINTAINER signatures for Block, RefState, and RefUpdate envelopes and verifies the signer against the local maintainer trust policy before publishing.

Key Input and Local Trust Store

Current key input is intentionally minimal. The CLI reads AUTHOR key material from PRIKK_AUTHOR_KEY_ID and PRIKK_AUTHOR_SEED, and MAINTAINER key material from PRIKK_MAINTAINER_KEY_ID and PRIKK_MAINTAINER_SEED. The seed values are caller-provided 32-byte Ed25519 secret seeds encoded as 64 hex characters. Prikk does not provide local secret storage, key generation, or public-key derivation. For the current setup workflow and seed-handling warnings, see the security and signing setup guide.

The local maintainer trust store supports a set of repository-local adopted MAINTAINER keys, with required = 1 continuing to mean any one adopted key’s signature suffices. prikk trust maintainer add adds a new key id to the set, or idempotently confirms an already-adopted id’s matching key; it refuses to replace an adopted id’s key with a different one. This refusal is a trust-on-first-use rule: the first public key seen for a key id is the one trusted for that id, permanently, until an operator removes it out-of-band. There is no remote trust distribution.

What Seal Checks

Seal requires --allow-no-audit, a valid local branch ref, a non-empty active WAL, valid active ref metadata matching the requested ref, and no trailing partial WAL bytes. It verifies that the configured MAINTAINER signer matches the repository-local trust policy before publication. It then persists Patch objects, signs and writes the Block and RefState, durably appends the ref pointer as the commit point, appends exactly one signed RefUpdate, confirms pointer/log agreement, and clears active state. Signer-backed retry is also the only authority that may finish an exact interrupted publication.

Current seal does not run audit plugins, evaluate attestation policy, perform semantic merge, publish multi-parent merge Blocks, or provide remote trust distribution.

What Verify Checks

prikk verify is read-only. It checks persisted object placement and identity, envelope decoding, Block references, ref pointer/log consistency, active WAL records, active WAL metadata health, rollback-draft structure for active and sealed rollback-marked Patches, and publication trust for Block, RefState, and RefUpdate envelopes against the repository-local maintainer trust policy.

verify does not prove that a repository is globally trustworthy. It does check every reachable Patch’s AUTHOR signature against recorded key material (DC-53), and fails when one does not verify or when a key_id’s recorded material contradicts itself — but that is continuity, not identity. It does not enforce historical PKI semantics, AUTHOR revocation, rotation, expiration, threshold policy beyond required = 1, remote policy, hosted identity, or complete crash-proof durability.

Rollback-Draft Boundary

Rollback drafts are Patch objects whose payload purpose is PatchPurpose::RollbackDraft. Active rollback-draft verification requires exactly one active WAL record, rejects trailing partial WAL bytes, requires a rollback-draft Patch purpose, requires an AUTHOR Ed25519 signature, rejects the legacy placeholder marker key id, requires 64-byte signature payloads, and compares the active payload with the inverse Patch derived from the current ref.

This is structural and semantic validation for the supported rollback subset. It is not rollback authorization and does not publish rollback refs. Repository-wide AUTHOR verification is performed by verify, not here (DC-53); this path’s own checks are unchanged.

Threat Boundaries

Current protections target local repository corruption, malformed persisted data, wrong object placement, ref pointer/log drift, active-WAL ownership drift, unsigned or untrusted publication objects, and legacy rollback marker signatures. Diagnostics should avoid raw text spans, replacement text, blob bytes, absolute host paths, .prikk private paths, signer secrets, key material, and arbitrary object debug dumps.

Current non-goals include global identity trust, remote trust, hosted forge semantics, key lifecycle management, hardware signing, multi-maintainer thresholds, production audit policy, plugin execution, and stable repository-format migration.

Claim-to-Source Anchors

Provenance

This reference consolidates released records through DC-23 and DC-24. It supersedes stale v0.2.0-era notes that described MAINTAINER signing as deferred; the current released code signs publication objects with real MAINTAINER Ed25519 signatures and verifies them against local trust. DC-26 moved this current-state reference from rfcs/fdds/ into the published book without changing code, schema, trust, or CLI behavior.