Release checksums on GitHub

[Ghepardo]

Hi, how can I view the SHA256 checksum for a release on GitHub? I need such checksums for new easyconfig files in EasyBuild. Can’t find checksums anywhere! Thanks.

[lee-dohm]

Hello and welcome to the community @Ghepardo.

GitHub doesn’t have built-in support for checksums in Releases. The author of the release would have to include that information in the release notes.

Let us know if you have more questions.

[ssbarnea]

Considering that these archives are created by Github itself without use any user controllable Github action, sending the dead cat on the user side might not be the best approach.

If these archives would have being uploaded by our workflows, It could have made sense to say that we are supposed to add the checksums to the release notes.

Still, even in 2022, pressing the "release" button creates the effective release on github before even a workflow is triggered, when in fact the effective release should have being the result of a successful work run triggered by the release button from the user interface.

Yes, I know that I can make release pipelines that can be user triggered, but I cannot disable the release button from releases page, so nope, that is not ok as I cannot expect people not to press the button that bypassed the pipeline.

[AlexProgrammerDE]

This answer is incorrect. You do get at least a md5 (sadly not sha256) hash with your downloaded files via the content-md5 header. Here is my full answer: https://github.com/orgs/community/discussions/23512#discussioncomment-7856465

[drojf]

Looks like things have changed again, and the answer is now correct as the md5 is no longer included in the header, see https://github.com/orgs/community/discussions/23512#discussioncomment-10013377 (I realize this is posted by the person I am replying to, but just to save you the extra click)

[wangzuo]

https://github.com/wangzuo/action-release-checksums I created this github action for generating checksums in github release. It will automatically generate a checksums.txt for all assets uploaded to current tagged release.

[Ghepardo]

Hi, thanks and noted, @lee_dohm.

Given that GitHub is a software repository, it is very strange that it does not enforce checksums for releases. Otherwise, how is any consumer of the software to have confidence that their copy of it has not been tampered with or damaged? This is a basic requirement for any respectable repository.

[lee-dohm]

Ghepardo:

Otherwise, how is any consumer of the software to have confidence that their copy of it has not been tampered with or damaged?

Traditional checksum systems don’t give any real evidence that the file downloaded has not been tampered with or damaged. It only signifies that the person who was able to modify two separate files on the same server was able to make them agree. There is no evidence available to the person downloading those two files that the person who last modified them is someone they trust. For example, Linux Mint was compromised in exactly this way.

In order to offer evidence that a file has not been tampered with or damaged, it would require a digital certificate as part of the file itself, signed with a key that can be verified by a trusted mechanism. The GitHub releases system works well with these kinds of protocols. When using one of these protocols, checksums are superfluous.

[Ghepardo]

Thanks @lee-dohm for your excellent observations, from which I have learned much.

[Daniel-Chin]

In my case, an installer file (70MB) takes forever to download from Amazon S3 (20KB/s) and it always times out before completion. I had to download it from other sources, but I want to verify that the downloaded file is identical to the release on Github.

Providing a hash of the release files would be valuable to many users.

[melMass]

SHA256 is pretty solid and definitely not easily reproducible!
But besides security concerns, this is still used by many package managers for instance (Conda, Conan, Brew to name a few) so it seems natural to have it generated on upload, is this considered?

Thanks

[MartinX3]

I also miss checksums.

If I would make one myself, maybe the file got corrupted while downloading it on my machine.
If I want to use the github API in an application, I need to verify, that the downloaded file is 1:1 the same on the github server.

[chapati]

While there are still many attacks when sums are just published on the same site with the release, sums still do their job to prove that:

• there was no man in the middle
• file was not damaged due to software/connectivity issues

Moreover many package managers REQUIRE AND ENFORCE presence of checksums. If you want to download something in your automated builds you MUST specify checksum. Ignoring this just makes github and its flows extremely unfriendly to software engineers. Making this question as solved just show that github pays little attention to its users’ problems.

[vertigo220]

I agree that checksums should be standard on GitHub releases, and there are multiple reasons to do so as well as ways to deal with the security weaknesses of doing so. However, I don���t think commenting here is going to do anything to encourage that or even likely be seen by anyone who can push to make that happen. I may be wrong, but I think the GitHub feedback is the place to do so, so I created an issue there. Everyone who agrees checksums are important and should be added should +1 that issue.

[fxstein]

This can be accomplished by Github Actions.

Here is a primitive release action I have created for a project that calculated the sha256 when a release is published:

# release.yml - Automatic creation of sha256 for release tarball

name: goprox release action
run-name: ${{ github.actor }} is publishing release ${{ github.ref_name }}
on:
  release:
    types: [published]
jobs:
  sha256:
    name: sha256
    runs-on: ubuntu-latest
    steps:
      - name: Tarball url
        run: echo "${{ github.server_url }}/${{ github.repository }}/archive/refs/tags/${{ github.ref_name }}.tar.gz"
      - name: Create tarball sha256 
        run: curl -sL "${{ github.server_url }}/${{ github.repository }}/archive/refs/tags/${{ github.ref_name }}.tar.gz" | shasum -a 256 | cut -d " " -f 1

The one thing I am still looking for is a simple way to write that SHA 256 back into the release notes

[brsolomon-deloitte]

The one thing I am still looking for is a simple way to write that SHA 256 back into the release notes

Could potentially use the Releases API for this.

[smallstepman]

I expected this to be part of the Releases API

[smallstepman]

related to #16426 which also remains unanswered

[wangzuo]

https://github.com/wangzuo/action-release-checksums I created this github action for generating checksums in github release. It will automatically generate a checksums.txt for all assets uploaded to current tagged release.

name: Release

permissions:
  contents: write

on:
  push:
    tags:
      - "v*.*.*"

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Release
        uses: softprops/action-gh-release@v1
      - name: Checksums
        uses: wangzuo/action-release-checksums@v1

[AlexProgrammerDE]

It appears when downloading a file from GitHub releases, a content-md5 header is sent to the http client after the initial redirect to objects.githubusercontent.com. MD5 is of course not a "secure" hash, but if you want to verify the data you've received is not corrupted, it should be ideal. Users with poor internet condition may have corrupted downloads since tcp checksums may fail.
Here is the specification: https://datatracker.ietf.org/doc/html/rfc1864 (It's the 128 bit md5 hash represented as a base64 encoded string)

[gdimoff]

@AlexProgrammerDE I'm trying to reproduce this with curl, but I'm not getting any "content-md5" header for this URL for example https://github.com/M66B/FairEmail/releases/download/1.2211/FairEmail-v1.2211a-github-release.apk

Is it still valid ?

[AlexProgrammerDE]

I think it was unfortunately removed by GitHub. Likely because Content-Md5 was deprecated. Sadly the replacements for that header don't appear to be implemented.

[thewh1teagle]

I created https://github.com/thewh1teagle/checksum action for that so we can easily have checksum for the assets

[sevenc-nanashi]

I found header x-ms-blob-content-md5:

❯ xh -F https://github.com/VOICEVOX/voicevox/releases/download/0.23.0/VOICEVOX.Web.Setup.0.23.0.exe
HTTP/2.0 200 OK
accept-ranges: bytes
age: 173
content-disposition: attachment; filename=VOICEVOX.Web.Setup.0.23.0.exe
content-length: 1223856
content-type: application/octet-stream
date: Sat, 24 May 2025 11:47:20 GMT
etag: "0x8DD577E9A7568FF"
fastly-restarts: 1
last-modified: Thu, 27 Feb 2025 22:32:22 GMT
server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
via: 1.1 varnish, 1.1 varnish
x-cache: HIT, HIT
x-cache-hits: 1559, 0
x-ms-blob-content-md5: 7Ahbvx5yOi5Kmy7XeVJcSQ==
x-ms-blob-type: BlockBlob
x-ms-creation-time: Thu, 27 Feb 2025 22:32:22 GMT
x-ms-lease-state: available
x-ms-lease-status: unlocked
x-ms-request-id: d134324d-d01e-0006-1869-89d2ea000000
x-ms-server-encrypted: true
x-ms-version: 2025-01-05
x-served-by: cache-iad-kcgs7200171-IAD, cache-nrt-rjtt7900064-NRT
x-timer: S1748087240.518162,VS0,VE0

+-----------------------------------------+
| NOTE: binary data not shown in terminal |
+-----------------------------------------+

❯ ccsum ./VOICEVOX.Web.Setup.0.23.0.exe -a md5
ec085bbf1e723a2e4a9b2ed779525c49  ./VOICEVOX.Web.Setup.0.23.0.exe

❯ irb -r base64
3.4.2 :001 > Base64::strict_encode64(["ec085bbf1e723a2e4a9b2ed779525c49"].pack("H*"))
 => "7Ahbvx5yOi5Kmy7XeVJcSQ=="

[jgh-131]

I found header x-ms-blob-content-md5:

❯ xh -F https://github.com/VOICEVOX/voicevox/releases/download/0.23.0/VOICEVOX.Web.Setup.0.23.0.exe

x-ms-blob-content-md5: 7Ahbvx5yOi5Kmy7XeVJcSQ==

Sadly, this is now blocked. I don't understand why a core functionality that was so easy to obtain before, and is security focused, has not be made as accessible.

[sevenc-nanashi]

Update:
New releases now have SHA256 (I disabled all addons and I'm still seeing this)

The field is .assets[].digest. Old releases have null in that field.

[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/

[thewh1teagle]

Thank you!!

[jgh-131]

@tinaheidinger This is great, but is there any reason this security accessible information wasn't retained for backward compatibility (static file download, http header, etc.)?