Verify a Download

Check the Checksum

The release publishes SHA256SUMS.txt: one line per file, the SHA-256 of its bytes and its name. Every installer and both supply-chain documents in the release are listed in it. There is no separate list per platform and no file that is offered without one.

On Linux and Windows, with SHA256SUMS.txt and the download in the same directory:

That checks every file the list names and reports, per line, whether it matched. To check one file, compare its line: sha256sum Truffle-2.0.1-x64.AppImage prints the same digest the list carries. On macOS, shasum -a 256 <file> prints it; the digest is the same value on every system.

If a line reports FAILED, the file is not the file the release published. Do not run it.

Check the Provenance

Each downloaded file has a Sigstore bundle beside it, named <file>.sigstore.json. The bundle is a keyless signature: it records that a specific GitHub Actions workflow, at a specific commit, produced exactly these bytes, and it is filed in the public Rekor transparency log. Nothing shows the signature is valid, so it is verified with the identity it should have:

Both flags are the part that matters. The identity is the workflow that is allowed to publish a Truffle build, and the issuer is the GitHub OIDC service that vouches for it — without them, any signature by anything would pass. The same two values are stated in the provenance.json the release publishes, and the same command is printed in the release notes.

This is 2026's answer to an unsigned download: the public transparency log holds the record, and no long-lived key that could be stolen or leaked was used to make it. The verification runs offline once the bundle is downloaded.

The Evidence Files

Everything the checks above use is a file the release publishes, none of them requires a session, and all of them are listed in SHA256SUMS.txt:

• SHA256SUMS.txt — the checksum list the commands above read.
• provenance.json — the signing identity, the issuer, the transparency log, and one entry per signed file with its Rekor log index.
• desktop-sbom.cdx.json — a CycloneDX software bill of materials for the desktop build, and its own bundle, because the inventory of what is inside a build is only worth reading if it is signed like the build.
• The release page — every file, including the per-platform Sigstore bundles, and the same instructions in its notes.

The installers themselves are on the download page, which links one only for a platform the release documents actually list. The files above were published from commit c603fc185aa5fd2ee954d9d050fd9d6b88e00a0a, which is the value release-manifest.json records for this release and the value every bundle in it is bound to.

What This Proves

A matching checksum proves the file is the one the release published, and that nothing changed it in transit or on disk. A verified bundle proves the file was built by Truffle's release workflow running from the named repository at the recorded commit, and that the record is in a public log that cannot be rewritten without leaving the old entry behind.

Together they answer the two questions a download raises: is this the file, and who made it.

What This Does Not Prove

These builds carry no code signing certificate. There is no Authenticode signature on the Windows installer, no Developer ID signature and no notarization ticket on the macOS build, and no store review behind either. Windows SmartScreen and macOS Gatekeeper will both say so, and the download page repeats the way through each one.

There are also no GitHub artifact attestations for these files. Attestations are refused for the private repository that builds them, so the provenance travels as the Sigstore bundles and provenance.json instead. A guide that sent you to look for one would be sending you to a record that does not exist, which is why this page asks for nothing of the kind.

And this release is published as a prerelease, not as the repository's latest release, so a link built on /releases/latest/ does not resolve to it. The addresses on this page name the release's tag, which does.

Verification is worth doing and it is not the whole of safety: a build signed by the right workflow is still a build whose behaviour you are choosing to run. Read what it does, and check it before you run it rather than after.