Glossary

Look up a term from the packslip guides or the specification; each links to the page that explains it. How packslip works shows how they fit together.

Projects and parties

• Consumer: software that verifies or installs releases from their packslips, such as a package manager or mirror.
• Domain project: a project named after its vendor's host, such as mytool.example.com.
• Forge: a code host, github.com or gitlab.com, whose project names also say who signs. A forge project, such as github.com/owner/mytool, is named after a forge repository, whose CI is expected to sign its releases.
• Mirror: a repackager that keeps the vendor's digests but lists its own download URLs.
• Monorepo subpath: a path naming one tool of a GitHub repository, as in github.com/owner/repo/mytool.
• Project: the name a consumer asks for: a host and optional path, without a URL scheme, such as github.com/owner/mytool or mytool.example.com.
• Repackager: a third party, such as a registry or mirror, that signs a statement for another vendor's files.
• Stamping host: a third party, such as a registry, reviewer, or scanning service, that signs a release list of versions it has checked, each entry a stamp.
• Vendor: the project whose releases a packslip describes, which normally builds and signs them, unlike a repackager.

Release files

• Artifact: a release file the statement lists for consumers to select and download, such as an archive, installer, bare executable, or source tarball.
• Bundle: a Sigstore bundle, a signed statement plus its verification material. Release bundles and release lists are both bundles.
• Executable path: an executable's path inside an artifact, listed in its bin so consumers can put the command on PATH.
• Extensions: metadata under extensions, keyed by whoever defines it; packslip assigns it no meaning.
• Host requirements: an artifact's needs from the host, such as a minimum OS or glibc version, listed in requires.
• packslip: the format and its tools, and the everyday name for a release bundle.
• Predicate: the statement's packslip data, whose type, https://packslip.dev/release/v1 or https://packslip.dev/releases/v1, marks a release or a release list.
• Provenance: SLSA build provenance an artifact links by URL in its provenance list, for consumers to verify separately.
• Release bundle: a release's bundle, published as packslip.sigstore.json, or packslip.<subpath>.sigstore.json for a monorepo tool, with each / written as -. Also called a release manifest.
• Release list: a bundle that indexes a project's releases and records later changes, such as withdrawals. Consumers pin it separately from the releases. Also called a signed list.
• release.toml: the optional input to packslip create --manifest, neither signed nor published. Older CLI help calls it a TOML manifest.
• Resource: an item shipped for a purpose other than running the software, such as a completion script, man page, skill, or SBOM.
• Resource asset: a resource published as its own release file, named in the resource's asset field and listed as a subject.
• Statement: the in-toto JSON inside a bundle: subjects with file digests, and a predicate with the release's or list's metadata.
• Subject: a file name and its digests in a release statement, one per artifact and resource asset. Any other file, such as a checksum file, is left out.
• Supplementary list: a GitHub repository's optional release list, kept on its default branch, that withdraws, marks, or recommends releases on top of the ones GitHub lists.
• Variant: a token, such as fips, that tells apart builds for the same platform.

Signing

• Certificate identity: the signer a keyless certificate names, such as a workflow URL with its ref, which --identity matches in full and --identity-prefix by prefix.
• Fulcio: Sigstore's certificate authority. The certificates it issues to GitHub Actions and GitLab CI jobs record the signing repository and its ID.
• Issuer: the OIDC provider that vouched for a keyless signer, such as https://token.actions.githubusercontent.com for GitHub Actions.
• Key signing: signing with a long-lived Ed25519 key from packslip keygen, whose public key consumers pin.
• Keyless signing: signing with a CI job's OIDC identity through Sigstore. Fulcio's short-lived certificate names the workflow, so there is no long-lived key.
• Reusable workflow: another repository's workflow, called by a release job, which can sign the caller's releases.
• Signer: the identity that signed a bundle: a certificate identity and its issuer, or a public key.
• Sigstore: the open signing project whose bundle format, Fulcio, and Rekor packslip uses.
• Source repository: the repository whose workflow run signed a bundle, as its keyless certificate records. Consumers compare it with a forge project's repository.
• Transparency log: Rekor, Sigstore's public log of signatures, which gives each a verified integration time.
• Trust root: the Sigstore certificates and keys a verifier trusts.
• Unlogged bundle: a key-signed bundle with no transparency-log entry, created with --no-log, which consumers accept only when told to, as with --allow-unlogged.

Trust

• Evidence: what a repackager or stamping host records having checked.
• First use: a consumer's first install of a project, before it holds a pin.
• Lockfile: a committed file, such as mise.lock, that records each project's pin so every machine enforces the same signer.
• No-downgrade: the rule that refuses a trust change, meaning a changed signer or protection weaker than the last accepted release's, until a person approves it. packslip install takes approval as --accept-trust-change=<id>.
• Pin: to hold a project's releases to one signer; as a noun, that policy: an issuer with an identity or prefix, a public key, or the repository a signer fingerprint names.
• Pin file: a TOML file in pins.d naming projects and the signer packslip install must require for each.
• Repository ID: a forge's number for a repository, which survives renames and transfers and is never reused. Consumers remember it for a forge project's accepted releases. packslip install also remembers the ID of the repository that signs a keyless domain project.
• Signer continuity: the check that a release comes from the last accepted signer: for keyless signing, the same repository and, by default, the same workflow file.
• Signer fingerprint: ps1_ plus 26 characters derived from the forge's issuer and the repository ID, naming the signing repository whatever it is called. packslip pin prints it; --pin checks it.
• Workflow pinning: the default that a keyless project's later releases come from the same workflow file. A signed pin_workflow: false asks consumers to check only the repository.

Discovery and installation

• Bootstrap: installing a tool with packslip install instead of piping a script to sh.
• Channel: a version's first prerelease identifier when it is not numeric, such as beta in 1.2.0-beta.2.
• Discovery: how a consumer finds releases: through GitHub for a GitHub project, or through a domain project's release list.
• Expiry: a release list's expires_at time, after which consumers refuse it.
• Latest: what a request naming no version gets: the vendor's signed latest or, for a GitHub project without one, GitHub's latest release. With no recommendation, or when the recommended release is missing or ineligible, it gets the highest eligible version.
• Minimum release age: a consumer's wait after a release is logged before offering it, such as mise's minimum_release_age.
• mise: a tool version manager whose packslip: backend installs tools from their packslips.
• Prerelease: a version with a prerelease part, such as 1.3.0-rc.1, which consumers skip unless asked.
• Security release: a release marked security: true in a release list because it fixes a vulnerability.
• Sequence: a release list's counter, higher in each new list so consumers can refuse an older one.
• Source tag: the vendor's tag for a release, such as mytool-v1.2.3, kept as spelled in source.tag.
• Version: a release's signed semver 2.0.0 version, used to order and select releases.
• Well-known URL: where a domain project's release list lives: https://<host>/.well-known/packslip.json, or https://<host>/.well-known/packslip/<path>.json for a name with a path.
• Yanked: withdrawn in a release list, so consumers never select the release.