Skip to content

ci: pin autotag binary by version + sha256#145

Open
joemiller wants to merge 1 commit into
mainfrom
joem/autotag-sha-pin
Open

ci: pin autotag binary by version + sha256#145
joemiller wants to merge 1 commit into
mainfrom
joem/autotag-sha-pin

Conversation

@joemiller
Copy link
Copy Markdown
Member

Summary

Replace the deprecated git.io/autotag-install one-liner in .buildkite/Dockerfile.release with a direct download of autotag_linux_amd64 from a pinned release (v1.4.3), verified against a hardcoded SHA-256.

Why

  • The installer is generated by godownloader, which is itself deprecated upstream. It verifies the checksum file published with each GitHub release, but those checksums are mutable — anyone who can publish a release can publish matching checksums. There's no way to pin an out-of-band expected SHA.
  • autotag's maintainers are me and a couple of trusted ex-coworkers (incl. @will.milton) and I trust the code, but a compromise of the autotag-dev org or a maintainer account would silently flow into every pipeline that runs the installer. Hardcoding the SHA in our workflow makes that class of supply-chain attack fail loudly.
  • autotag rarely changes and we only use its most basic functionality, so we don't upgrade often. Grabbing the new binary's SHA from checksums.txt on bump is a cheap one-time step for meaningful hardening.

See: autotag README, CI install section.

Second commit bumps stale README version examples so the plugin-linter passes.

Test plan

  • Merge to main and verify the release container builds.
  • Verify the released plugin still tags + creates a GitHub release as before.

Replace the deprecated `git.io/autotag-install` one-liner with a direct
download of `autotag_linux_amd64` from a pinned release, verified against a
hardcoded SHA-256.

Why:
- The installer is generated by godownloader (also deprecated upstream) and,
  while it does check the checksum file published with each GitHub release,
  those checksums are mutable — anyone who can publish a release can publish
  matching checksums. There's no way to pin an out-of-band expected SHA.
- autotag's maintainers are me and a couple of trusted ex-coworkers
  (incl. @will.milton) and I trust the code, but a compromise of the
  `autotag-dev` org or a maintainer account would silently flow into every
  pipeline that runs the installer. Hardcoding the SHA in our workflow makes
  that class of supply-chain attack fail loudly.
- autotag rarely changes and we only use its most basic functionality, so we
  don't upgrade often. Grabbing the new binary's SHA from `checksums.txt`
  on bump is a cheap one-time step for meaningful hardening.

See: https://github.com/autotag-dev/autotag/blob/main/README.md (CI install
section) for the recommended pattern.
@joemiller joemiller requested a review from a team as a code owner May 14, 2026 23:11
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.

2 participants