Refuse to publish a tag that is not on main - #10
Merged
Conversation
Branch protection governs main; it says nothing about tags. The release build checked out the tagged commit and verified only that the tag matched _version.py -- a number, not a history. Anyone able to push a tag and publish a GitHub Release could therefore ship a commit that never passed review, and the deployment approval was the sole remaining control. Reproduced: a commit made off main with a backdoor added, tagged v1.2.2 with a matching _version.py, passes the version guard unchanged. The build now fetches main and refuses unless the tagged commit is reachable from it, before setting up Python or building anything -- an unreviewed commit should not produce an artifact at all. Verified the gate rejects the off-main tag and accepts both real tags, v1.2.1 and v1.3.0. Two supporting controls, applied to the repository rather than this file: - A ruleset blocking deletion and non-fast-forward updates of v* tags, so a published tag cannot be quietly repointed at different code. Note that tag rulesets cannot express "must be on main" -- there is no such rule type -- which is why the ancestry check lives in the workflow. - can_admins_bypass is now false on the pypi environment, so the approval wait applies to the owner too rather than being skippable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0114gUUe4CxYr8W8oC95ffmD
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
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.
Branch protection governs main; it says nothing about tags. The release build
checked out the tagged commit and verified only that the tag matched
_version.py -- a number, not a history. Anyone able to push a tag and publish
a GitHub Release could therefore ship a commit that never passed review, and
the deployment approval was the sole remaining control.
Reproduced: a commit made off main with a backdoor added, tagged v1.2.2 with a
matching _version.py, passes the version guard unchanged.
The build now fetches main and refuses unless the tagged commit is reachable
from it, before setting up Python or building anything -- an unreviewed commit
should not produce an artifact at all. Verified the gate rejects the off-main
tag and accepts both real tags, v1.2.1 and v1.3.0.
Two supporting controls, applied to the repository rather than this file:
published tag cannot be quietly repointed at different code. Note that tag
rulesets cannot express "must be on main" -- there is no such rule type --
which is why the ancestry check lives in the workflow.
applies to the owner too rather than being skippable.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_0114gUUe4CxYr8W8oC95ffmD