After you publish, download your release from the public location, in a clean directory, and run the same checks you ask users to run: checksum, signature identity, attestation and a test install. If any step needs a file only you have, your users cannot verify it either.
Why test the user path
Release pipelines often work for the author and fail for everyone else. The checksum file is missing, the signature points at the wrong identity, or the docs name a flag that no longer exists. A five minute check after each release catches those before a user, or an attacker offering a lookalike download, fills the gap.
Step 1: fetch from the public URL
Use a new directory and a machine or container that has none of your keys or config. Download from the public release page, not from a build artifact folder.
Step 2: check the checksum
sha256sum -c SHA256SUMS
A checksum catches corruption and mismatch, but if an attacker can replace both the file and the checksum, it proves little on its own. See checksum versus signature.
Step 3: verify the signature identity
For keyless signing, the Sigstore docs give this form:
cosign verify-blob FILE --bundle artifact.sigstore.json \
--certificate-identity=EXPECTED_IDENTITY \
--certificate-oidc-issuer=EXPECTED_ISSUER
Write the expected identity and issuer into your README, and use exactly those values in your own test. If the command only passes with values you had to look up in a log, your instructions are incomplete.
Step 4: verify the attestation
If you generate build provenance with GitHub's artifact attestations, the documented command is:
gh attestation verify PATH/TO/ARTIFACT -R ORGANIZATION_NAME/REPOSITORY_NAME
For container images, log in to the registry first and use the oci form with the image reference. The GitHub guide notes these commands assume an online environment and links to a separate guide for offline verification.
Step 5: install in a clean place
Install the package into an empty project and run its smallest example. For npm, you can also preview publish contents beforehand with a dry run of npm pack, as in check what you are about to publish.
What to record
| Item | Example note |
|---|---|
| Version and date | v1.4.0, 19 Oct 2026 |
| Checksum matched | Yes or no |
| Signature identity matched | Yes or no |
| Attestation verified | Yes or no |
| Clean install worked | Yes or no |
Keep this with your release notes. It also gives you evidence if someone later asks how you verify builds. A verified signature still says who built the file, not that the code is safe; read what package provenance proves.
Safeguard can scan the dependencies of what you ship and produce an SBOM; the free scan is at gold.safeguard.sh/scan.
Quick check
Should I run verification on my own laptop?
Better to use a clean machine or container, so you do not rely on keys or config only you have.
Does a passing check mean the release is safe?
No. It shows the file matches what was signed and by whom, not that the code is free of defects.
Sources
Last reviewed: 19 October 2026.
