Suppose a desktop application is available from both its release page and a mirror. The filenames and version numbers match, but users still need answers: are these the same file, who published them, do they come from the expected code and build process, and are they appropriate to run on this device?
Those questions require different evidence. Calling every verification method “security certification” invites expectations that the methods cannot meet and can cause developers to overlook gaps in their release process.
Checksums answer whether files match
Computing a hash after downloading and comparing it with an expected value can establish whether the file contents match. An important condition is that the expected value comes from a trusted channel. If both the file and its checksum come from the same unverified page, their agreement does not establish the publisher’s identity.
Conversely, a different hash means the files differ, but does not by itself prove malicious intent. Different builds, repackaging, or an incorrect download can all cause differences. Stop treating the file as a verified release and reconfirm its source, target platform, and corresponding checksum record.
Publishers should maintain clear filenames, version information, and checksum inventories together. Users should not have to copy a hash from an old article and compare it with an installer for another platform or another build.
Signatures require checking the expected identity
A digital signature associates a signer with signed data, but verification must also determine whether that identity is the expected one. Sigstore’s verification documentation requires checking signatures alongside relevant identity and issuer conditions, illustrating this distinction. Sigstore verification documentation
When users see “valid signature,” they should also establish which publisher or workflow it represents. Developers should specify which identities may sign official releases. Any signature that passes a mathematical check must not automatically confer official-release status.
When publishers change certificates or signing methods, they also need to provide an explanation that users can verify. Asking users to trust an unfamiliar certificate on the spot is not a complete update process.
Build provenance connects a package to its production process
GitHub artifact attestations can record build provenance, helping verify an artifact’s association with repository and workflow information. They provide evidence about how a file was produced, but verification still needs to check the actual artifact and the expected identity. GitHub artifact attestation documentation
SLSA’s build levels further distinguish the existence of provenance records, signed provenance generated by a hosted platform, and stricter protections for the build platform. When citing a level, state its scope and supporting evidence rather than treating the number as a score covering every software risk. SLSA build levels
| Evidence | What it primarily helps establish | What it cannot establish on its own |
|---|---|---|
| Checksum | Whether the expected file contents were obtained | Publisher identity or safe program behavior |
| Digital signature | Who signed which data | Whether the signer meets your trust requirements |
| Build provenance | Which build process produced the artifact | That all source code and dependencies are problem-free |
| Reproducible build | Whether the same artifact can be rebuilt under specified conditions | That the software has no vulnerabilities or improper behavior |
These forms of evidence can complement one another. Developers should explain what they provide and which checks still need to be completed independently.
Reproducible builds require explicit inputs and environments
The Reproducible Builds project defines a reproducible build as one that produces bit-for-bit identical specified artifacts from the same source code, build environment, and build instructions. This is a more precise verification target than “it compiles on my computer.” Definition of reproducible builds
We recommend retaining the toolchain, dependency lock information, build parameters, and their relationship to release artifacts. If reproducibility has not been achieved, accurately record how far rebuilding succeeds instead of omitting differences and declaring a pass.
The scope of a public repository also needs explanation. It may contain core source code, or it may primarily contain build tools, configuration, and application packages generated upstream. Users need to know which parts they can actually inspect and rebuild to assess provenance evidence reasonably.
A practical download-checking sequence
- Confirm the release repository through the project’s official entry point, rather than relying only on search advertisements or forwarded links.
- Read release notes and verify the operating system, processor architecture, and release channel.
- Compare the file with its corresponding checksum. Where signatures or provenance are available, verify the expected identity and scope as well.
- Check maintenance status and known limitations, without assuming that the “latest” tag means suitable for production use.
- When information conflicts, retain the version and filename and seek clarification through the project’s support channels.
This process does not require every user to become a build engineer. Products can organize complex evidence into a clear release page explaining where files come from, whom they suit, how to check them, and where to ask about discrepancies.
For developers, maintaining that information chain over time is more valuable than applying a one-off “verified” badge. Users should still be able to find relevant explanations when an old release is withdrawn, a signing method changes, or an update fails.
AlphaBiz’s public repository description distinguishes build tools from application bundles generated upstream. When discussing desktop applications of this kind, we should likewise describe the actual inspection scope instead of conflating a public repository, complete source code, and reproducible releases. AlphaBiz project overview
Developers can begin by completing a release-evidence inventory; users can start by checking one download for an application they use frequently. Share the verification information you would like release pages to provide in AlphaBiz Discussions.