TenkaCloud Docs

Security and provenance model Stable

A problem pack must be reproducible and tamper-evident. The facts below are normative reference derived from the pack manifest's inert-by-design schema and the immutable snapshot / lock model in the pack installer.

Guarantees

Inert manifest (no executable hooks) Stable
v1 manifests carry no author credentials, remote URLs, scripts, or executable hooks. The schema is .strict(), so every unknown top-level field is rejected.
Immutable content-addressed snapshots Stable
Installing a pack hashes a canonical, sorted file list and the bytes of each file into a SHA-256 content digest. Re-installing the same id+version with a different digest fails closed.
Pinned Git provenance Stable
A git-sourced pack records the HTTPS repository URL (credentials stripped), the resolved immutable 40-hex commit, and the subdir. Fetch is shallow, hooks-disabled, and resolves only the pinned commit — never a floating ref.
No remote / mutable sources Stable
The only source kinds are 'local' (a directory) and 'git' (a pinned commit). There is no mutable / floating reference path and no runtime code execution during install.

How provenance is recorded

Every installed revision is recorded in the lock with its content digest and source kind. A git-sourced pack additionally records the HTTPS repository URL (with credentials stripped), the resolved immutable 40-hex commit, and the subdir. The content digest is source-kind-agnostic, so the same bytes always produce the same digest regardless of how they were fetched.

What a pack cannot do

A v1 manifest cannot declare scripts, lifecycle hooks, remote URLs, or credentials. Install performs no runtime code execution. The Git fetch is shallow, hooks-disabled, and resolves only the pinned commit — it never follows a floating branch or tag.

Related: pack manifest reference.