The chain of trust.

Verification happens at fetch and install, never per run. What lands in the store carries its proof with it, and what runs has already been believed, exactly once.

Figure 1 — The trust flow: a published artifact plus its sha256 sidecar, verified at install, then runs with no re-verification; unsigned is first-class and loud.

The top link of the chain is made once, offline, by the project owner, with a witness, and nothing about it is improvised. The runbook is docs/root-ceremony.md in the product repository; it produces, in order:

The private keys move to hardware tokens from two vendors and to two offline backups, and the factories sign with a subkey held in CI secrets, never with the root primary. The only public outputs are the fingerprints and the armored public keys, which are wired into EMBEDDED_ROOT_FINGERPRINT (filled when the ceremony minted the classical root on 2026-09-09), published on this site, and mirrored to the org’s .github repository and the keyservers. Rotation and revocation are rehearsed on a scratch keyring before the first signed release: the runbook publishes the pre-made successor and observes trust forward, then publishes a revocation and observes the revoked fingerprint fail closed (RevokedKey, exit 72) even on previously-valid artifacts.

Version 2 puts the integrity material between the slot table and the header, keeping the header exactly where readers of v1 expect it, at EOF with the version field still 1. Signing is flagged by TPKG_FLAG_SIGNED_V2 (bit 1 of package_flags), which old readers pass through untouched: runtimes of the v1 era keep reading v2 packages exactly as before, and they simply do not verify. The same gap also carries typed extension blocks (a type-2 block holds the package manifest), and the signing extension, when present, stays last before the header, unchanged. The authoritative reference is crates/tpkg/src/lib.rs.

Detection works as follows: the reader parses the v1 header at EOF as always, and if the signed flag is set, the extension, exactly 256 + 8 + sig_len + 4 bytes, sits immediately before the header, self-delimiting from the tail through its sig_len field, with the digest tail zeroed. Typed ext blocks before it walk forward from the end of the slot table (type + length self-delimit); readers aware of the v1 era skip unknown block types (forward-compat), while tebako-pkg validate rejects them with a named error. A trailer with the flag clear has no extension and parses exactly as v1, which is the legacy-unsigned case below.

crates/tebako-signer is the one OpenPGP half of the chain: rnp-rs over librnp with vendored botan (PQC-capable; #![deny(unsafe_code)] with one documented FFI exception). The crate owns detached sign/verify, which classifies into Trusted / Untrusted / Invalid, the outcomes onto which the named trust errors map, and its rewrite operations (insert-image / remove-image / set-runtime / reassemble) preserve the input’s signing state. The store has two homes under $TEBAKO_HOME:

First-party slices verify against the embedded tamatebako root, with zero interaction, ever. A third-party author’s slices verify against the author’s own key, and everything turns on how a machine learns the right fingerprint. No channel is trusted alone, and two channels agreeing is the trust event:

Continuity is the security property. After the first confirmation, every artifact from that identity must verify against the pinned key. A mismatch fails closed (SignerKeyChanged, exit 72) and displays both fingerprints; a valid successor chain forwards automatically after displaying the chain proof and re-pins the new key. The management verbs (tebako trust list|show|remove) and re-verification of installed artifacts by tebako doctor are planned.

Tebako touches cryptography for three different questions, and the crypto consolidation decision gives each question exactly one home, never two overlapping mechanisms at the same layer:

The OpenPGP chain is the only authenticity decision point, for every backend; a slice author manages exactly one keypair, and format-native keys never enter keys/ or trust/. ENC is the only tebako decryption path, and a self-encrypted limnifs image (aead ≠ 0) fails ENOTSUP at mount. A limnifs in-image signature, when admitted, may be verified only as non-authoritative integrity evidence, after the OpenPGP chain has decided and against a key that the signed metadata binds to the author; absence is never an error, and a mismatch warns and journals. That evidence role is the planned part: its binding addendum is not committed, and today tebako ignores embedded bundles.

Verification failures are named exit codes with full message bodies, never silent and never a crash. The trust codes (70/71/72) sit in the loader’s full named set:

The end-to-end behavior is the following: a tampered runtime download is refused with the sha error; a tampered image slot names its sha256 mismatch at first run; an unregistered signer key is exit 72, a trust error rather than a crash.

The package-side machinery is shipped, and so is the release side: since v2.6.0 every released artifact carries its detached .asc signature beside the sha256 sidecar, the release manifest and the checksum index are object-signed, and the root-key ceremony has minted the classical root that this site publishes and the tools embed. What remains is the loader’s signature check: loader-side revocation consumption (the format is locked), and the return of the OpenPGP verification feature to the shipped bootstrap via the tebako-crypto toolkit payload. Until that lands, signed packages run under the loud unverified-first posture described above, with TEBAKO_REQUIRE_SIGNED=1 failing closed for hardened environments.

See also: Verify integrity · The store