Report vulnerabilities privately; other bugs go in issues.

Open a private advisory at https://github.com/jdx/packslip/security/advisories/new. Include what you can:

• The component and version: packslip version output, package version, action ref, packslip.sh URL, packslip-verify.mjs commit, or image digest.
• The command and files, including any wrongly accepted release bundle, release list, or artifact.
• What an attacker gains and needs first.
• Whether it is public or reported elsewhere, and how to credit you.

Keep details out of public issues, pull requests, and discussions until the advisory is published. If the form fails, open an issue asking only for a private contact.

Everything this repository ships, and the packslip.dev and packslip.sh services:

• The CLI and its APT and RPM packages.
• The crate, npm package, Go module, and image (ghcr.io/jdx/packslip).
• The jdx/packslip and jdx/packslip/releases actions, installer/, verifier/packslip-verify.mjs, skills/packslip/SKILL.md, the specification, tests/conformance/, and the release workflows.

Examples:

• A verifier (the CLI, crate, npm package, or committable verifier), or a spec rule or conformance vector, lets through a bundle, list, or file that should be refused, such as a disallowed signer or a mismatched digest.
• Without --allow-other-repository, a forge project's release verifies although its certificate's source repository is not the project's. Signing with another repository's reusable workflow is accepted by design.
• packslip install installs a project or version other than the one requested, selects a withdrawn release, accepts an expired or rolled-back release list, writes outside its directories, runs downloaded code, or replaces a pinned signer without approval.
• An install script installs an executable whose SHA-256 differs from the one written in it, or runs anything else it downloads.
• A publishing tool (packslip create, packslip releases, the Go module, an action) signs something that misdescribes its input, lets an input run a command, or exposes a token.
• The agent skill tells an agent to weaken verification without cause, such as with --allow-unlogged.
• Either service serves a file a release did not publish, or someone other than the maintainers gets a release signed by packslip's release workflow.

• A vulnerability in a tool that publishes with packslip, or a release signed by its compromised signer: report it to that project. A verified bundle establishes who signed and that the files match, not that the software is safe (How trust works).
• Sigstore's services and GitHub's OIDC tokens and attestations: report to them; packslip mishandling their material is in scope.
• The packslip support in mise and the mise registry (mise's security policy).
• Trust you grant by flag (--allow-*, --accept-trust-change, --trusted-root) or by naming a signer, key, or identity (--pin, --pubkey), when the flag does what its help says. A flag that grants more is in scope.
• A mistyped or lookalike name.
• Trust on first use: for a keyless domain project, packslip install trusts the signer its list names (fetched over HTTPS from its host) and the repository that signed its first list and release. For a forge project, it trusts the repository the forge reports for the name. Passing the signer fingerprint with --pin on every install avoids both.
• Documented limits: packslip verify neither fetches build provenance nor checks a release list's expiry or sequence, and the committable verifier skips the checks its header lists. A check a consumer is documented to enforce but skips is in scope.
• A dependency's vulnerability: report it to that project, and here too when packslip is exploitable through it.
• Attacks that need code execution as the user running packslip.
• Denial of service by traffic volume.
• Scanner output without demonstrated impact.

1. The maintainers discuss the report with you in the advisory, with no fixed response time, and close a report that is not a packslip vulnerability with an explanation.
2. A confirmed vulnerability is fixed, possibly in the advisory's private fork. The fix is public on main before its release, but its pull request and commits do not describe the vulnerability until the advisory is published.
3. The release is marked a security fix in packslip.dev's signed release list, so consumers can shorten their minimum release age for it.
4. The advisory is then published with the affected and fixed versions.

Only the latest 1.x release is supported; earlier releases are not patched. The CLI, crate, npm package, Go module, actions, install scripts, and image share one version number. The committable verifier is supported as it stands at the latest release's tag.

Reinstall the CLI the way you installed it, and move each pinned copy to the fixed release:

• A https://packslip.sh/vX.Y.Z or https://packslip.sh/vX.Y.Z/install.ps1 URL, and any checksum for it (such as ADD --checksum).
• An @vX.Y.Z or @<full-commit-sha> action ref, and its packslip-version and packslip-sha256 inputs (or remove them).
• An X.Y.Z image tag or digest, and the executable packslip-path names.
• A committed packslip-verify.mjs: copy it from the fixed tag.
• A dependency: cargo update -p packslip, npm install packslip@latest, or go get github.com/jdx/packslip/go@latest.

@v1, the unversioned packslip.sh URLs, and the latest and X image tags move to each release (pull the image again). An X.Y tag moves only within its minor line. Under @v1, packslip-version and packslip-path still pin the CLI; packslip-sha256 set alone fails the job until updated.

Distributions choose the versions they maintain; fixes are kept suitable for backporting (Maintaining packaged verifiers).