To help ensure authenticity of packages some projects on GitHub and on GitLab add hashsums to the descriptions of the release on the Releases page.

Sometimes, at least here, the hashsum are made part of the release's filename. Sometimes, at least here, a script generates a file with hashsums that's uploaded to the releases.

However, many projects don't add these hashsums to their releases. They aren't automatically added and not always posted in a findable way somewhere else on the Web.

I proposed adding hashsums to the Releases page of Kodi but was told that the hashes (of files in the Releases of a GitHub project) can change in the case of GitHub. Is that really true? Doesn't this diminish the authenticability of builds/files distributed this way?

I think ensuring authenticity of builds requires at least:

  • them to be reproducible (reproducible-builds)
  • a mechanism to verify that one has the reproducible software and not something else
  • a mechanism to allow developers to authorize, sign and audit the software/changes to it
  • a mechanism to ensure that the reproducible software is installed - and remains unaltered - and not something else.

I thought that a very easy-to-implement and convenient step towards this for projects distributed via GitHub or GitLab would be simply adding hashsums (e.g. simply the SHA256 hashsum of the tarball or .deb file). What would a more complete mechanism look like? And more importantly: can hashsums of GitHub releases really change? Why and wouldn't this mean that the authenticity of releases there can't be ensured? How come some projects add them to release's description in that case?

  • 1
    I think what wsnipex is saying is that the tar that you get from github can be different each time which would correspond to a different hash.
    – MikeSchem
    Commented Oct 29, 2020 at 18:40
  • Yes. How is this any different than what I wrote above? I was proposing adding hashsums to each of the releases, like other projects are already doing.
    – mYnDstrEAm
    Commented Oct 29, 2020 at 18:56
  • Here is a related question (also added an answer there) opensource.stackexchange.com/q/10083/13675
    – mYnDstrEAm
    Commented Oct 11, 2021 at 9:07

2 Answers 2


GitHub dynamically generates a tar.gz file when a user downloads a source release for a git tag. The hashes for those files are not stable, as they are dependent on the versions of git, tar, and gzip involved. These hashes have changed in the past, which has affected various package repository/build systems.

Source: https://github.com/libgit2/libgit2/issues/4343#issuecomment-328631745

Another issue listing issues from projects bitten by this before: https://github.com/spack/spack/issues/5411

The best way to get verifiable source dumps from GitHub is to clone the repository and check out the commit hash associated with the tag. The next best thing is to have the project generate its own tar.gz files and upload them as release artifacts, but that's a lot of extra work for little return (I'd only recommend it if the project gets a large amount of download traffic).


It depands on how the release (files) are made. If they use the on-the-fly generated files, those are not considered to be identical each time. (Has to do with how GitHub creates those files and cache optimization)

If they create there own release files (so a build street creates, compiles, signs, hashes and packages the release) than you can absolutely use hashes. Those provided files should not change.

Also to make a release (tag) more authentic the creator of the release should sign it with the git-gpg sign functionality. This would convey who created the release and whether this person is in fact part of the team validating a release.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .