Question about checksum verification UX in lazygit releases

[damonzwicker]

Quick question about the verification step in lazygit releases—

When downloading a binary, people run shasum/sha256sum and then compare hashes. That last step—comparing 64-character hashes by eye—is where things tend to break down (either skipped or done loosely).

I put together a minimal example that keeps the same checksum model but removes that comparison:

npx verafile verify file proof.json → VALID / INVALID

Example:
https://github.com/damonzwicker/verafile/tree/main/examples/open-source-release

Not about replacing signing—just turning verification into a clear result instead of a manual check.

Would simplifying that step increase how often people actually verify downloads?

[anubhavaanand]

The comparison step isn't actually the weak link here, which is why I'd be careful about what problem a shorter command solves.

checksums.txt is served from the same host as the binaries. Anyone positioned to swap the binary is positioned to swap the checksum file with it, so a passing hash tells you the download wasn't truncated — it doesn't tell you the artefact came from lazygit. Making that comparison a single keystroke cheaper raises how often people run a check that was never much of a security control to begin with. The gap you're describing is real, but it sits at "where did the integrity data come from", not "was step 3 tedious".

The thing worth flagging is that these releases aren't signed at all right now. .goreleaser.yml has a checksum section producing checksums.txt, and release.yml has no cosign, no artifact attestation, no --sign — it also publishes under a repo-scoped PAT rather than the workflow token, so GitHub's own attestation wouldn't be generated either. Which means the eye-comparison you're describing is currently the strongest verification this project offers. That's the more interesting version of your question.

On the UX point itself, sha256sum -c already produces the VALID/INVALID verdict you're after, with no new tooling and no npm package added to the chain:

curl -sLO https://github.com/jesseduffield/lazygit/releases/download/v0.45.2/checksums.txt
curl -sLO https://github.com/jesseduffield/lazygit/releases/download/v0.45.2/lazygit_0.45.2_Linux_x86_64.tar.gz
grep lazygit_0.45.2_Linux_x86_64.tar.gz checksums.txt | sha256sum -c
# lazygit_0.45.2_Linux_x86_64.tar.gz: OK

and on tampering, which I also checked by flipping a byte:

lazygit_0.45.2_Linux_x86_64.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

Exit status is 0/1, so it drops into CI as a gate with nothing to install (shasum -a 256 -c on macOS). cosign verify-blob against the checksum file is the step that would add actual trust — and it's also one command with a clear verdict, which is really the property you're asking for.

Where I'd grant your premise: the failure modes are ugly enough that people do bounce off it. If the filename in that grep doesn't match exactly — Linux is capitalised in the asset names, linux isn't — you feed sha256sum an empty stream and get "standard input: no properly formatted checksum lines found", which reads like a broken checksum file rather than a typo. A silent no-match is a genuinely bad signal. If you want to improve this upstream, sha256sum -c --strict --warn plus a line in the README's install section is the change I'd open a PR for, and it's smaller than either of us needs it to be.

[Icaro0310]

The eyeball-comparison step isn't actually necessary — sha256sum already does the comparison for you with -c. lazygit ships a checksums.txt in every release in exactly the format it expects:

curl -LO https://github.com/jesseduffield/lazygit/releases/latest/download/checksums.txt
curl -LO https://github.com/jesseduffield/lazygit/releases/latest/download/lazygit_0.44.1_Linux_x86_64.tar.gz

sha256sum -c checksums.txt --ignore-missing
# lazygit_0.44.1_Linux_x86_64.tar.gz: OK

Non-zero exit on mismatch, no manual diff. On macOS it's shasum -a 256 -c checksums.txt.

So I'd argue the fix is documenting this in the README rather than a new tool — one less binary to trust before you can verify the binary you actually wanted. Worth noting this only verifies integrity against the published checksum file, not authenticity of the release itself; for that you'd want signed checksums (e.g. cosign via GoReleaser).

—
More of my work lives here: github.com/Icaro0310 · Website: icaro0310.github.io