Question about checksum verification UX

[damonzwicker]

Quick question about the verification step in bat 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?

[BLCCoreStudio]

Yes — removing the manual comparison of two 64-character hashes is a genuine UX improvement, but I would keep one security distinction clear.

A checksum answers whether the downloaded bytes match the expected bytes. Trust still depends on where the expected checksum or proof came from. If proof.json is fetched from the same potentially compromised location as the binary, turning the result into VALID/INVALID improves usability but does not add publisher authentication.

For release tooling, I think the strongest UX is:

• one command that returns an explicit success or failure result;
• no manual hash comparison;
• fail closed on malformed or missing verification data;
• keep the checksum or proof tied to a trusted release channel or, ideally, a signature or provenance mechanism.

So yes, I would expect a simpler verification flow to increase actual verification rates. The important part is making verification easier without making the user think the simplified UX provides stronger authenticity guarantees than the underlying checksum model does.