Add automatic and consistent checksums to releases

[vertigo220]

As discussed here, checksums should really be a standard feature on GitHub. While I realize they don't provide as much protection against tampering as signatures, they should still be used for a variety of reasons:

1. very few projects use signatures;
2. checksums are easier for most people to use;
3. signatures aren't even necessarily secure since most people don't have an established web-of-trust in order to verify the signature they're using is actually legit;
4. the checksums could be calculated on initial upload only (i.e. if a file is modified after it's uploaded, the checksum would stay the same and not be recalculated) then stored on a different site, so even if someone gained access to GitHub and was able to modify files maliciously, they would have to gain access to the secondary site simultaneously in order to modify the checksums, vastly increasing the security provided; and
5. at the very least, they will provide the ability to verify file integrity, which is almost as important, especially for those on slower or unstable connections, and is a universal benefit, making it in a way more important as it's helpful to everyone.

Finally, not only should they be added, but the process should be automatic so it doesn't rely on the repo maintainer, and it should be standardized, to allow for checking automatically with a tool (download/package manager, etc). It would require very little overhead, storage, and bandwidth, practically no extra time once set up, and would offer significant benefit.

[iuuky]

Checksums are also useful in situations when you want to automatically download latest releases with the same name. To prevent re-downloading latest, but unchanged, releases, you could just check whether the checksum changed. Currently, you have to keep track of versions externally.

[na-jakobs]

Please add a checksum for Releases zip files that are generated on the GitHub side 🙏

[victor1234]

CMake FetchContent needs shecksum for example.

[smallstepman]

should also be a part of Releases API

[untereiner]

is it so difficult for a large staff like github's one to take one hour to add to release API a function that makes a call to another function that computes a checksum ?

[BinToss]

Some GitHub Release assets have x-ms-blob-content-md5 (e.g. x-ms-blob-content-md5: cbkmFuAcae8MdmibRTG3GA==) in the response header. Unfortunately, I couldn't use this for validation—the MD5 hashes never match (cbkmFuAcae8MdmibRTG3GA== from response header vs XE3dX3R3zAvtXsHpEferSQ==). See learn.microsoft.com/en-us/answers/questions/282572/md5-hash-calculation-for-large-files.

[tinaheidinger]

Releases now exposes SHA256 digests for (newly published) release assets: https://github.blog/changelog/2025-06-03-releases-now-expose-digests-for-release-assets/

[felipecrs]

Could you also serve the SHA256 digest without GitHub API? For example, you could return a plain text with the checksum at <asset url>.sha256.

That would make scripting the checksum verification much simpler (which should be encouraged), without requiring parse of API JSON output.

[BinToss]

That would be convenient for those who need the checksum files, but I'd argue the Release file list UI would need a way to hide or minimize checksum files so end users only see the files that matter to them. When targeting multiple platforms (i.e. binary releases for different operating systems, CPU arch, Linux package formats, etc.), the current iteration of the file list becomes cumbersome.

Edit: If the UI remains unchanged, then my concerns are a non-issue.

[felipecrs]

Yeah. I didn't mean to have the .sha256 attached as an asset.