ci(sanitize): refuse to move an existing release tag - #74
Open
rob-p wants to merge 1 commit into
Open
Conversation
The sanitize job fired on any push to main whose head commit message contains the tag marker, then created the sanitized commit with `git tag --force` / `git push --force`. Re-pushing an already-released head commit (e.g. resetting main after an accidental push) therefore re-ran the job on the same source SHA and silently repointed the release tag at a fresh commit. The tree is identical in that case, but GitHub stamps archive member mtimes from the commit date, so the generated source tarball changes bytes and its sha256 changes with it -- which broke checksum verification for downstream packagers (#73). Check origin for the tag first and fail loudly if it exists, and drop both --force flags so the tag can never be moved implicitly. Re-releasing a version now requires deleting the tag by hand.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the mechanism behind #73.
What happened
sanitize-cargo.ymlruns on any push tomainwhose head commit message contains the tag marker, and tagged withgit tag --force+git push --force. On 2026-07-20mainwas reset back to3dec905after an accidental push of dev work; that force-push replayed a push event whose head commit was the already-releasedv0.10.3commit, so the job ran a second time on the same source SHA and repointed the tag:2a640e25(Jul 16 12:35:23Z)a2e296fb(Jul 20 03:43:41Z)b84e6524b84e6524(identical)3dec90583dec9058(identical)The release contents never changed — identical tree SHA — but GitHub stamps archive member mtimes from the commit date, so the generated
v0.10.3.tar.gzchanged bytes and its sha256 went from4fb1d812…toe952fae1…, breaking checksum verification downstream (Homebrew).Release assets and crates.io were unaffected: the re-run Release workflow failed at
host(release already exists) andPublish to crates.iowas skipped.The change
Query
originfor the tag before doing anything and fail with a clear::error::if it already exists, then tag and push without--force.Trade-off: legitimately re-cutting a version now requires deleting the tag by hand first. That is the intent — moving a published tag should be a deliberate, human action, not a side effect of a force-push.
🤖 Generated with Claude Code