Read the Introducing packslip announcement for the motivation behind the format and examples of using it with mise.
What a packslip does
Publish packslip.sigstore.json beside your release artifacts. It contains
the files’ digests, platform metadata, executable paths, and links to
resources and build provenance. Consumers verify the manifest against a
trusted identity or key, then check the files they download.
A GitHub release job can sign with its workflow identity. Publishers outside supported CI can use an Ed25519 key. Both produce an in-toto statement in a sigstore bundle.
Follow the release workflow to see how local configuration becomes a signed bundle and how consumers find it.
Inside a packslip
Here is the release statement for a small portable tool, shortened to show its core fields. The bundle wraps this metadata with a signature; the digest below is abbreviated.
{
"subject": [{
"name": "mytool-1.2.3.tar.gz",
"digest": { "sha256": "..." }
}],
"predicateType": "https://packslip.dev/release/v1",
"predicate": {
"project": "mytool.example.com",
"version": "1.2.3",
"artifacts": [{
"name": "mytool-1.2.3.tar.gz",
"url": "https://mytool.example.com/releases/1.2.3/mytool-1.2.3.tar.gz",
"format": "tar.gz",
"bin": ["bin/mytool"]
}]
}
}
subject records the file’s digest. artifacts describes where to get
it, how to unpack it, and which executable it contains. The signed
project and version identify the release. Platform-specific releases
also name their OS, architecture, and libc.
Create this example and read the field-by-field explanation , or explore the full specification .
Choose your next step
| If you… | Start here |
|---|---|
| Want to try the format | Create and verify a local sample |
| Publish software | Add packslip to your GitHub release job |
| Need to describe a complex release | Configure artifacts |
| Download software or build an installer | Understand verification and trust |
| Want a consumer example | Use packslip with mise |
Describe the release once
A consumer can read the platform and executable paths from the signed manifest instead of maintaining filename guesses for each vendor. Resources can include completions, man pages, CLI specifications, agent skills, SBOMs, and desktop files. Host requirements describe libraries and commands the software needs.
The metadata travels with the release, so a publisher can change an archive layout and describe the new layout in the same release. Consumers decide which formats and resource kinds they support.
Know what verification proves
A verified packslip authenticates a signer’s statement about the release. Checking an artifact against it establishes that the downloaded bytes match the signed digest. A checksum downloaded beside a binary cannot provide that independent signer check on its own.
Build provenance is separate evidence and must be verified separately. A single manifest does not detect withdrawn releases or prevent rollback: those checks require discovery metadata and consumer state. Signed release lists provide expiry, sequence numbers, withdrawals, and an optional recommended version.
Read the format
The specification defines the release and release-list predicates, signing schemes, and consumer rules. The CLI reference documents the generator and verifier.
packslip is developed by Jeff Dickey , author of mise and usage . The format is stable at version 1 . Feedback is welcome.
