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.
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?