Publish sha256 alongside the release binary and verify on install (closes #12, #1)

[dolph]

Closes #12.
Closes #1.

Summary

Publishes a sha256 of the release binary as a release asset, and has install.sh (and the README quickstart) verify the binary against that checksum before doing anything with the bytes. Also fixes the long-standing curl bug from #1 — curl -L -o https://... was missing its filename, so the documented install path didn't actually work.

This is Tier A from the issue body. Tier B (.goreleaser.yml for cross-compile + Cosign signatures) is a strictly bigger scope conversation that pairs with #15; left as a follow-up.

Changes

.github/workflows/go.yml

New step before the release upload, gated on the same tag predicate, plus the new file in files::

- name: Generate checksum
  if: startsWith(github.ref, 'refs/tags/v')
  run: sha256sum ussher > ussher.sha256

- name: Release
  uses: softprops/action-gh-release@v1
  if: startsWith(github.ref, 'refs/tags/v')
  with:
    body_path: README.md
    files: |
      ussher
      ussher.sha256

install.sh

Download block rewritten end-to-end:

if ! [ -f ussher ]; then
    curl -fLO https://github.com/dolph/ussher/releases/latest/download/ussher
    curl -fLO https://github.com/dolph/ussher/releases/latest/download/ussher.sha256
    sha256sum -c ussher.sha256
fi

This single block fixes three things:

• install.sh: curl -o is missing its filename argument, breaking the binary download #1: the broken -o syntax (-O derives the filename from the URL — same effect, no foot-gun).
• --fail: a 404 / 5xx from GitHub no longer silently writes an HTML error page that then gets chmod +x'd.
• Release artifacts have no checksum or signature — adopters can't verify what they install #12: actual integrity verification. set -e at the top of install.sh means a mismatch aborts before sudo install runs.

The verification only runs when install.sh just downloaded the binary — if a local ussher already exists (the ./build.sh && ./install.sh build-from-source flow), the script trusts it and skips both downloads. That keeps the local-build flow working without a sidecar .sha256 file. The trust model there is "you built it yourself", which is fine.

README.md

The "Recommended installation & usage" step 1 now shows the parallel curl + sha256sum -c commands for adopters who skip install.sh and follow the README manually. The "don't proceed past this step on a mismatch" instruction is called out explicitly.

Test plan

• shellcheck install.sh build.sh passes (the existing CI job from Add shellcheck to CI (refs #1) #6/Simplify shellcheck discovery to .sh only (review feedback from #6) #7 will also catch this on the PR).
• Local dry-run of the new sequence: ./build.sh produces ussher; sha256sum ussher > ussher.sha256 followed by sha256sum -c ussher.sha256 round-trips cleanly.
• ./build.sh still green; tests pass; coverage unchanged at 39.5%.
• CI shellcheck + build jobs both green on the PR.
• (post-merge) First tag push produces both ussher and ussher.sha256 as release assets; the README quickstart steps run end-to-end against that release.

Out of scope (follow-ups)

• .goreleaser.yml for cross-compiled binaries and Cosign signing — pairs with Release only ships a single linux-amd64 binary — no arm64, no darwin #15 and is a strictly bigger scope. The lines this PR adds will be replaced wholesale if/when goreleaser lands; this PR is a strict improvement on the current state in the meantime.
• A behavioral CI test of install.sh's download block (the test plan I sketched on install.sh: curl -o is missing its filename argument, breaking the binary download #1's comment thread). Worth adding but widens scope; happy to do it as its own PR if you want.

https://claude.ai/code/session_013HnepY8MhhxrJJjE5ysW47

---

Generated by Claude Code