Skip to content
All posts
2 min readtebakoarchitecturepackaging

Architecture: Trust and the release chain (5 of 5)

How tebako v2 works, concept by concept — this post: trust and the release chain.

The Tebako team

github.com/tamatebako
Note

Post 5 of 5 in the series Tebako v2 architecture.

○ ○ ○ ○ ●

  1. Architecture: The three-part package

  2. Architecture: The runtime as an image

  3. Architecture: Composition

  4. Architecture: The host boundary

  5. Architecture: Trust and the release chain (this post)

The previous four posts covered what a package is and how it runs. This last one covers why you can believe the bytes: how artifacts are built, published, verified, and kept verifiable.

The chain is short and every hop is verified:

  • Factories build and publish. Runtime factories and payload feedstocks build per platform and publish release artifacts with SHA-256 sums.

  • A registry points, it does not serve. A registry is one YAML file hosted anywhere a file can live — your own releases, any git host. It mirrors only what resolution needs; the artifact stays with the publisher.

  • The store verifies at entry. When an artifact enters ~/.tebako, it is checked against the published SHA-256 and then kept read-only. Runs never re-verify — the question was answered at install time, which is why runs stay fast.

Trust and the release chain from factory to run, every hop verified the factory builds and signs your release artifacts + SHA-256 the registry one YAML file the store verified at entry verification happens when an artifact enters the store — never per run payloads stay byte-identical with what the publisher released

Figure 1 — Artifacts flow from the factory through your release and a registry into the store, verified when they enter.

Unsigned is first-class, and honest

A package without a signature works, with a loud warning and a journal entry. A stricter policy — TEBAKO_REQUIRE_SIGNED=1 — fails closed on anything unverifiable. Signing is per-package opt-in, and verification of signed artifacts is always strict.

Byte-identical, always

The store never re-wraps, re-stitches, or patches a downloaded artifact. What your users run is byte-identical with what you published; the digest beside it is the proof.

The series, and what comes next

That is the whole model: three-part packages, runtimes as images, a composition grammar, a host boundary, and a verified release chain. The basic payloads series puts all five concepts to work hands-on, and the advanced series shows them carrying its most demanding workload.

Note

This is the end of the series Tebako v2 architecture. Continue with Basic payloads, part 1 next.