packslip is a signed release manifest for software distributed as archives, installers, or executables. Publish packslip.sigstore.json beside your release files so consumers can verify their digests, select a platform, and find executables, resources, and build provenance.
Start here
How packslip fits a release explains the path from local build files to signed metadata and installation, including which parts belong to the publisher, CLI, and consumer.
- Try it locally: Getting started walks through creating and verifying a manifest without a CI account.
- Publish a release: GitHub Actions covers the release workflow, inputs, and monorepos.
- Describe your files: Artifact configuration covers platforms, executables, TOML configuration, and host requirements.
- Consume a release: Verification explains trust pins and the checks an installer must perform.
- Host your own releases: Release lists covers discovery, withdrawals, and the recommended version, and Host releases on your own domain publishes a project’s releases and list from GitHub Actions to a host you run.
For exact fields and rules, read the specification, CLI reference, or JSON schemas.
Add it to a GitHub release
To keep third-party actions away from release write access, run packslip in a separate job with read-only release access with upload: false, then upload its bundle from a job you control. The existing one-step form below still uploads by default and needs contents: write.
Add this step to a tag-triggered release job after building the artifacts and creating the GitHub release:
permissions:
contents: write
id-token: write
attestations: write
steps:
# Build the archives and create the release before this step.
- uses: jdx/packslip@v1
with:
artifacts: dist/*.tar.xz dist/*.zip
bin: mytool
The action attests the matched files, hashes the artifacts, signs the manifest with the workflow’s identity, verifies the bundle, and uploads it to the existing release. It does not upload your binaries. Consumers can pin the repository’s identity without managing a signing key. A second action, jdx/packslip/releases, builds a project’s signed release list from the bundles it has published.
The action and CLI share a version: @v1 follows CLI 1.x releases, and @v1.0.0 pins both to 1.0.0. By default, the action installs the CLI version from its own commit’s Cargo.toml. Set packslip-version to explicitly override that selection.
Bring your own CLI
packslip-path runs an executable that is already on the runner — a path, or a name to look up on PATH — instead of downloading a release archive. macOS releases are arm64 only, so an x64 macOS job builds the CLI first and points the action at it:
runs-on: macos-15-intel
steps:
- uses: dtolnay/rust-toolchain@stable
- run: cargo install packslip --version 1.0.0 --locked --root "$RUNNER_TEMP/packslip"
- uses: jdx/[email protected]
with:
packslip-path: ${{ runner.temp }}/packslip/bin/packslip
artifacts: dist/*.tar.xz
bin: mytool
Install the version the action ref pins; the two are released together. The same applies to any runner a release archive does not suit: a platform packslip does not ship, a self-hosted or network-restricted machine, or a job that would rather build from source than download. packslip-path takes precedence over packslip-version, and a binary the action did not download is not verified, so the job vouches for it.
Agent skill
Packslip publishes a skill for release configuration, resources, and verification. With a release that includes the skill, mise can fetch the matching version and link it into your agent’s skill directory:
mise use packslip:packslip.dev
mise skills sync --dir .agents/skills
The generated link is local to your installation; keep it out of version control and run sync again after changing tool versions.
Work on packslip
See CONTRIBUTING.md for setup, checks, and documentation sources, and RELEASING.md for the maintainer release process. The format is stable at version 1; see Stability for what that fixes and what a revision may add. Bug reports and format feedback belong in issues.
Developed by Jeff Dickey (@jdx), author of mise, and Shunsuke Suzuki (@suzuki-shunsuke), author of aqua. MIT licensed; see LICENSE.
Summary
Signed release manifest for vendor binaries (jdx; packslip.dev): packslip.sigstore.json beside release artifacts — digests, platform metadata, executable paths, resources (completions, man pages, CLI specs, AGENT SKILLS, SBOMs), build provenance. Signed via GitHub workflow identity (keyless sigstore) or Ed25519; in-toto statement in a sigstore bundle. Consumers verify against trusted identity, then check downloads.
Learnings
- The supply-chain answer to the Cilium CI doctrine’s ‘pin by SHA’ pattern, generalized: instead of every consumer maintaining filename guesses + checksums per vendor, the vendor ships ONE signed self-describing manifest. mise consumes it; aqua-registry’s author (szkdash) co-develops it. The agent-skills-tied-to-version resource kind is the forward-looking bit. Pair with the Golden repo CI section and hk/mise toolchain.
Gotchas
- (none yet)
Hands-on
(watch: vendors adopting; try verifying a packslip’d release with mise)