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.

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 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.

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/packslip@v1.0.0
    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.

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.

Created by Jeff Dickey (@jdx), author of mise and usage. MIT licensed; see LICENSE.