You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(signing): require active tag rulesets for release tags in the verifier - #1210
Part of #1206. Step 1 of 2: make the release-tag verifier independent of github.ref_protected.
Both release workflows require github.ref_protected == true on the v* tag push. GitHub's variables reference says that is true when rulesets apply to the ref, but community reports (discussion 142985, discussion 66588) describe it staying false for tag pushes. If that is the case on the real tag push, both verifier jobs are skipped and nothing publishes. Because release-tags-immutable has no bypass actor, the pushed tag could then not be deleted or moved, so the version would be unusable. No v* tag was created to probe this.
What changes
verifyRemoteTag now reads the repository's active tag rulesets (GET /rulesets?targets=tag, then one detail per active repository ruleset) and requires that creation, update, deletion and non_fast_forward are all covered for refs/tags/<tag>. Coverage may be split across rulesets.
It fails closed on: no ruleset, a disabled or evaluate-only ruleset, a non-tag target, an inherited ruleset whose rules cannot be read, a different include pattern, an excluded ref, unknown pattern syntax (a pattern outside a safe subset never matches an include and always counts as an exclude), a failed list request, and a list of 100 or more entries that may be truncated.
The check runs after the signature and protected-main ancestry checks and before the final tag ref re-read.
refPatternMatches is exported and tested directly.
Evidence
Live, read-only and unauthenticated: the real signed tag v1.29.2 passes the full verifyRemoteTag path, including the new ruleset coverage for refs/tags/v1.29.2. This also shows the check works with a low-privilege caller, which is what the workflow token is.
verifyRemoteTag (44) and signing (72) tests pass locally, including 11 new rejection cases, a split-ruleset acceptance case and the pattern table.
Known limit
The API hides bypass_actors from callers without admin rights, so this check cannot prove that no actor can bypass release-tags-immutable. That stays a setting a maintainer verifies with an authenticated read (done: no bypass actors on ruleset 26812769). It is documented in docs/VERIFIED-SIGNING.md.
Next step
The workflows pin the verifier to 147470682b62, so they do not run this code yet. After this merges, a second small PR moves the pin in docker.yml, tauri-build.yml, scripts/release-security-gate.mjs and the gate test to the resulting protected-main commit and drops the github.ref_protected condition. Until then the workflows keep their current conditions.
Release boundary
No tag, GitHub Release, registry push or Vercel mutation. This PR does not authorize v1.29.3.
Summary by Sourcery
Harden release-tag verification by validating complete active ruleset protection directly through the GitHub rulesets API.
Bug Fixes:
Require release-tag verification to confirm that active repository tag rulesets fully protect the pushed tag, rather than relying on unreliable protected-ref status.
Enhancements:
Fail closed when tag ruleset coverage is missing, inactive, unsupported, excluded, unreadable, or potentially truncated, while allowing protection to be distributed across multiple rulesets.
Documentation:
Document active tag ruleset verification and the limitation that bypass-actor validation requires an authenticated maintainer check.
Tests:
Add coverage for ruleset protection scenarios, safe ref-pattern matching, split ruleset coverage, and fail-closed rejection cases.
Chores:
Update the changelog and README test-count metrics.
Summary by cubic
Makes release-tag verification depend on active tag rulesets read directly from the rulesets API rather than github.ref_protected, which community reports say stays false for tag pushes. The verifier now requires creation, update, deletion and non-fast-forward coverage for the pushed ref and fails closed on disabled, evaluate-only, mis-targeted, excluded, or unreadable rulesets.
Coverage may be split across several active repository rulesets.
bypass_actors remains visible only to admins, so the no-bypass guarantee stays a maintainer's authenticated-read check, documented rather than enforced by the verifier.
Pattern syntax outside a supported safe subset, including double stars, is treated as unknown and never matches, so it cannot be used to grant or deny coverage. Matching uses an iterative glob so no pattern text reaches a regular expression.
Rollout
Workflows still pin the verifier to the prior commit, so release behavior is unchanged; a follow-up moves the pin and drops the github.ref_protected condition.
Written for commit 6aeb415. Summary will update on new commits.
CodeAnt-AI Description
Require active tag rulesets for release verification
What Changed
Release-tag verification now checks active rulesets for the pushed tag instead of relying on GitHub’s protected-ref status.
Verification requires creation, update, deletion, and non-fast-forward protection; coverage can be split across rulesets. Missing, unreadable, or unsupported protection fails verification.
Impact
✅ Rejects release tags without full protection ✅ Accepts protection split across active rulesets ✅ Verifies tag protection when GitHub’s protected-ref status is unreliable
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by CodeRabbit
Bug Fixes
Release tag verification now checks active repository rulesets to confirm the pushed tag is covered by rules for creation, updates, deletion, and non-fast-forward changes. Verification also requires the ruleset information to be fully retrieved.
Documentation
Updated the verified-signing policy to describe the tag ruleset checks and relevant visibility limitations.
…ifier
github.ref_protected is reported as false for tag pushes even when a ruleset applies, which would skip the release verifier jobs and leave an immutable tag unusable. Read the active repository tag rulesets in the verifier and require that creation, update, deletion and non-fast-forward all cover the pushed ref, failing closed on disabled or evaluate-only rulesets, other targets, excluded refs, unknown pattern syntax and an unreadable or possibly truncated list. The workflows keep their current conditions until the pin moves to this commit.
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).
Limit details: You’ve used the included review currently available. Your 72 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.
Reviewing files that changed from the base of the PR and between 675af20 and 6aeb415.
Files selected for processing: 2
scripts/signing/verify-remote.mjs
tests/unit/tooling/verifyRemoteTag.test.ts
Walkthrough
The tag verifier now checks active repository tag rulesets for complete coverage of tag creation, update, deletion, and non-fast-forward operations. The change adds ref-pattern matching, updates verification tests, and revises signing documentation and reported test counts.
Changes: Release tag verification
Layer / File(s)
Summary
Ruleset matching and verification scripts/signing/verify-remote.mjs, scripts/signing/verify-remote.d.mts
The verifier matches supported patterns against tag refs and requires active repository tag rulesets to collectively cover four tag operations. It rejects unreadable or potentially incomplete ruleset data.
Mocks now provide ruleset API responses. Tests cover split and insufficient ruleset coverage, inactive or inapplicable rulesets, unreadable or potentially truncated results, and pattern matching.
Policy documentation and test counts CHANGELOG.md, docs/VERIFIED-SIGNING.md, README.md
The changelog and signing policy describe the ruleset checks. The README updates the reported test count from 8721+ to 8725+ and retains the 656-file count.
Merge Risk: Low · previous review 675af
The release-tag verifier's glob matching may differ from GitHub's for unusual nested tag patterns. Normal single-segment release tags are unlikely to be affected. This can be fixed before or shortly after merge.
Explain the verifier’s ruleset requirements and bypass-actor visibility limit, and clarify the signing snapshot table formatting.
CHANGELOG.md L10
README.md L23-1032 (4 small edits)
docs/VERIFIED-SIGNING.md L15-19, L66-69
Tests
Exercise ruleset API responses, complete and split protection coverage, fail-closed cases, and supported or unknown ref-pattern matching.
tests/unit/signing.test.ts L897-914
tests/unit/tooling/verifyRemoteTag.test.ts L44-87, L105-132, L296-480 (+4 small edits)
Tips and commands
Interacting with Sourcery
Trigger a new review: Comment @sourcery-ai review on the pull request.
Continue discussions: Reply directly to Sourcery's review comments.
Generate a GitHub issue from a review comment: Ask Sourcery to create an
issue from a review comment by replying to it. You can also reply to a
review comment with @sourcery-ai issue to create an issue from it.
Generate a pull request title: Write @sourcery-ai anywhere in the pull
request title to generate a title at any time. You can also comment @sourcery-ai title on the pull request to (re-)generate the title at any time.
Generate a pull request summary: Write @sourcery-ai summary anywhere in
the pull request body to generate a PR summary at any time exactly where you
want it. You can also comment @sourcery-ai summary on the pull request to
(re-)generate the summary at any time.
Generate reviewer's guide: Comment @sourcery-ai guide on the pull
request to (re-)generate the reviewer's guide at any time.
Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
pull request to resolve all Sourcery comments. Useful if you've already
addressed all the comments and don't want to see them anymore.
Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
request to dismiss all existing Sourcery reviews. Especially useful if you
want to start fresh with a new review - don't forget to comment @sourcery-ai review to trigger a new review!
Reviewing files that changed from the base of the PR and between 7df9f17 and 675af20.
Files selected for processing: 7
CHANGELOG.md
README.md
docs/VERIFIED-SIGNING.md
scripts/signing/verify-remote.d.mts
scripts/signing/verify-remote.mjs
tests/unit/signing.test.ts
tests/unit/tooling/verifyRemoteTag.test.ts
Included review availability: This review used your included allowance. 0 included reviews remain after this review. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour.
1. An active inherited tag ruleset is skipped without reading its rules; when local rulesets cover all four protections, verification succeeds despite the unreadable inherited policy.
Without a documented guarantee of how GitHub matches a double star across path separators, an include match could over-match and an exclude could under-match. Treat any pattern containing it as unknown, which never includes a ref and always excludes it, so ruleset coverage cannot depend on that semantics.
…xpression
CodeQL reported incomplete escaping where the pattern was turned into a RegExp. Match the restricted pattern subset with an iterative glob matcher in which star and question mark never consume a path separator, so no pattern text reaches a regular expression.
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
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.
User description
Summary
Part of #1206. Step 1 of 2: make the release-tag verifier independent of
github.ref_protected.Both release workflows require
github.ref_protected == trueon thev*tag push. GitHub's variables reference says that is true when rulesets apply to the ref, but community reports (discussion 142985, discussion 66588) describe it stayingfalsefor tag pushes. If that is the case on the real tag push, both verifier jobs are skipped and nothing publishes. Becauserelease-tags-immutablehas no bypass actor, the pushed tag could then not be deleted or moved, so the version would be unusable. Nov*tag was created to probe this.What changes
verifyRemoteTagnow reads the repository's active tag rulesets (GET /rulesets?targets=tag, then one detail per active repository ruleset) and requires thatcreation,update,deletionandnon_fast_forwardare all covered forrefs/tags/<tag>. Coverage may be split across rulesets.refPatternMatchesis exported and tested directly.Evidence
v1.29.2passes the fullverifyRemoteTagpath, including the new ruleset coverage forrefs/tags/v1.29.2. This also shows the check works with a low-privilege caller, which is what the workflow token is.verifyRemoteTag(44) andsigning(72) tests pass locally, including 11 new rejection cases, a split-ruleset acceptance case and the pattern table.Known limit
The API hides
bypass_actorsfrom callers without admin rights, so this check cannot prove that no actor can bypassrelease-tags-immutable. That stays a setting a maintainer verifies with an authenticated read (done: no bypass actors on ruleset 26812769). It is documented indocs/VERIFIED-SIGNING.md.Next step
The workflows pin the verifier to
147470682b62, so they do not run this code yet. After this merges, a second small PR moves the pin indocker.yml,tauri-build.yml,scripts/release-security-gate.mjsand the gate test to the resulting protected-main commit and drops thegithub.ref_protectedcondition. Until then the workflows keep their current conditions.Release boundary
No tag, GitHub Release, registry push or Vercel mutation. This PR does not authorize
v1.29.3.Summary by Sourcery
Harden release-tag verification by validating complete active ruleset protection directly through the GitHub rulesets API.
Bug Fixes:
Enhancements:
Documentation:
Tests:
Chores:
Summary by cubic
Makes release-tag verification depend on active tag rulesets read directly from the rulesets API rather than
github.ref_protected, which community reports say staysfalsefor tag pushes. The verifier now requires creation, update, deletion and non-fast-forward coverage for the pushed ref and fails closed on disabled, evaluate-only, mis-targeted, excluded, or unreadable rulesets.bypass_actorsremains visible only to admins, so the no-bypass guarantee stays a maintainer's authenticated-read check, documented rather than enforced by the verifier.Rollout
github.ref_protectedcondition.Written for commit 6aeb415. Summary will update on new commits.
CodeAnt-AI Description
Require active tag rulesets for release verification
What Changed
Impact
✅ Rejects release tags without full protection✅ Accepts protection split across active rulesets✅ Verifies tag protection when GitHub’s protected-ref status is unreliable💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by CodeRabbit