How to verify where a download came from

A checksum tells you whether a download matches another copy of the same file. To learn who built it and from which source, you also need a signed build record. Checking both connects the software on your disk to the release you chose.

This matters for a local tool such as GhostGet, which can work in accounts you connect. You can inspect the public source and then verify that the downloaded package came from the project’s release workflow.

Checksums and build records answer different questions

A checksum is a fingerprint of a file’s bytes. If one byte changes, its checksum changes. Comparing a download with a published checksum catches corruption or a mismatch, but someone who replaces both can make them agree.

A signed build record, also called an attestation, binds that fingerprint to an identity. GhostGet’s record identifies the repository, source commit, version tag, and GitHub Actions workflow that built the package. The GitHub CLI verifies the signature and checks those identities against the ones you require.

A successful verification establishes origin. It is not a review of the source code or its dependencies; those need their own evaluation.

Download one release into its own directory

Install and sign in to the GitHub CLI. Choose a version from GhostGet’s releases, then replace <version> in the commands with that number:

gh release download v<version> -R hraness/ghostget --dir ghostget-<version>
cd ghostget-<version>
shasum -a 256 -c SHA256SUMS

Keep the package and its companion files together. SHA256SUMS records the file fingerprints, release-manifest.json records the package identity, and provenance.jsonl contains the signed build records.

Verify the builder and the version

Require the GhostGet repository, its release workflow, and the selected tag. The following command also requires a GitHub-hosted runner:

gh attestation verify hraness-ghostget-<version>.tgz   -R hraness/ghostget   --bundle provenance.jsonl   --signer-workflow hraness/ghostget/.github/workflows/release.yml   --source-ref refs/tags/v<version>   --deny-self-hosted-runners

A successful check exits with status zero. Add --format json to inspect the verified identity. If the check fails, investigate the reported mismatch before installing the file.

You can also check that the file belongs to the immutable GitHub Release:

gh release verify v<version> -R hraness/ghostget
gh release verify-asset v<version> hraness-ghostget-<version>.tgz -R hraness/ghostget

Install the file you checked

bun add --global ./hraness-ghostget-<version>.tgz
ghostget --version

Installing the local file preserves the connection between the verification and the package you run. The getting-started guide continues with your first page read and account connection.

For an npm installation, run npm audit signatures in the project that contains it to check registry signatures and package provenance.