Skip to content

fix(upgrade): detect same-version re-cut releases via checksum staleness#9

Merged
Harsh-2002 merged 1 commit into
mainfrom
dev
Jun 4, 2026
Merged

fix(upgrade): detect same-version re-cut releases via checksum staleness#9
Harsh-2002 merged 1 commit into
mainfrom
dev

Conversation

@Harsh-2002

Copy link
Copy Markdown
Owner

Summary

orva upgrade was blind to same-day re-cut releases. Date tags (vYYYY.MM.DD) are re-cut under the same tag when we ship more than once a day, but the upgrader compared only the semver tag — so a user who upgraded earlier the same day was told "already the latest" after a re-cut, even though the published binary changed.

Fix: when the latest tag isn't strictly newer, also compare the running binary's SHA-256 against the published checksum for its platform asset (latest.AssetName looked up in latest.ValidationAssetURL — both already returned by go-selfupdate). A mismatch ⇒ a fresh build under the same tag ⇒ reinstall.

  • upgradeAction — pure decision (force | versionNewer | rebuilt).
  • remoteBuildDiffers — best-effort checksum probe; known=false on any network/parse failure ⇒ falls back to version-only (10s bounded fetch, never hangs/blocks the upgrade).
  • fileSHA256 / remoteAssetSHA / parseChecksums helpers.
  • --check now reports newer build available (same version, rebuilt).

Self-contained: the slim CLI can't import backend/internal/version (no commit to compare), and the release already publishes checksums.txt. No tag-scheme change, no new deps.

Validation

  • go build ./... && go vet ./... && go test -race ./cli/commands/ green; new upgrade_test.go covers the decision truth table, hasher, checksums parsing (two-space + *name), and remoteBuildDiffers over httptest (equal / differ / absent / no-validation-url).
  • Live: a binary stamped v2026.06.04 but built locally (different bytes) → upgrade --check correctly reports "newer build available (same version, rebuilt)"; an older tag still upgrades by version; an unreachable repo fails gracefully without hanging.

Notes

  • Known edge (documented): running orva upgrade on the full server binary sees a mismatch vs the CLI asset and offers to replace it — same direction as a version bump; orva upgrade is the CLI self-update path (servers update via install.sh/Docker).
  • CLI-only: cli/commands/upgrade.go + tests + cli/CLAUDE.md.

Date tags (vYYYY.MM.DD) get re-cut under the same tag when we ship more than
once a day, so an equal tag can point at a different published binary. `orva
upgrade` compared only the semver tag, so a user who upgraded earlier the same
day was wrongly told "already the latest" after a re-cut.

When the latest tag isn't strictly newer, also compare the running binary's
SHA-256 against the published checksum for its platform asset (latest.AssetName
in latest.ValidationAssetURL) and reinstall on a mismatch. Self-contained: the
slim CLI can't import backend/internal/version (no commit to compare), and the
release already publishes checksums.txt.

- upgradeAction: pure install decision (force | versionNewer | rebuilt).
- remoteBuildDiffers: best-effort checksum probe; returns known=false on any
  network/parse failure so it falls back to version-only (10s bounded fetch,
  never hangs/blocks the upgrade).
- fileSHA256 / remoteAssetSHA / parseChecksums helpers.
- --check now reports "newer build available (same version, rebuilt)".
- upgrade_test.go: decision truth table, hasher, checksums parsing (two-space
  and *name forms), and remoteBuildDiffers over httptest (equal/differ/absent/
  no-validation-url).

Verified live: a binary stamped v2026.06.04 but built locally (different bytes)
correctly reports a rebuilt build is available; older tags still upgrade by
version; an unreachable repo fails gracefully without hanging.
@Harsh-2002 Harsh-2002 merged commit 8e026b9 into main Jun 4, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant