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.