fix(ci): resolve tag from API instead of workflow_run context#29
fix(ci): resolve tag from API instead of workflow_run context#29
Conversation
Removes head_branch as a tag source, which was attacker-controlled and triggered CodeQL's untrusted-checkout and code-injection alerts. TAG is now resolved from inputs.tag (manual dispatch) or the releases API (workflow_run), validated, then passed via step output instead of GITHUB_ENV.
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughIntroduces a "Resolve and validate tag" step in the GitHub Actions release workflow that derives a tag from input or latest release, validates it, exposes it as Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release-arm64.yml:
- Around line 32-33: The current gh api call using "repos/${{ github.repository
}}/releases/latest" only returns published releases and can pick the wrong tag;
update the TAG assignment to call "repos/${{ github.repository }}/releases"
(which returns drafts too) and extract the appropriate tag_name (e.g., use --jq
'.[0].tag_name' or filter by draft/created_at as needed) so TAG is set from the
most recent release object including drafts; ensure you keep the same TAG
variable and replace the existing gh api invocation accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 13d38810-7011-4313-a62a-e048365de7c9
📒 Files selected for processing (1)
.github/workflows/release-arm64.yml
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release-arm64.yml:
- Around line 32-36: The current gh api call that sets TAG by selecting
.[0].tag_name must be replaced with a lookup that matches the release whose
target commit equals the triggering run's head SHA; use
github.event.workflow_run.head_sha (or GITHUB_SHA) rather than taking the first
release. Update the TAG assignment logic (the variable TAG and the gh api call)
to query releases and filter with a --jq expression that returns the tag_name
for the release where .target_commitish (or .target_commit) ==
github.event.workflow_run.head_sha, and keep the existing error/exit path if no
matching release is found.
- Around line 29-30: The run step is directly interpolating ${{
github.event.inputs.tag }} into the shell which can cause command injection;
instead export the workflow_dispatch input as an environment variable (e.g.,
env: INPUT_TAG: ${{ github.event.inputs.tag }}) and in the script refer to the
shell variable (INPUT_TAG) when setting TAG and performing the regex check;
update the lines that set TAG (currently using ${ { github.event.inputs.tag }})
to use the shell variable (e.g., if [[ -n "$INPUT_TAG" ]]; then TAG="$INPUT_TAG"
), then proceed with the existing validation logic so the expansion happens in
the shell and is validated rather than expanded by GitHub Actions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a996b761-0f8f-4943-9236-5e3e6afc0a93
📒 Files selected for processing (1)
.github/workflows/release-arm64.yml
1 participant
Problem
CodeQL flagged 7 critical alerts in
release-arm64.yml:actions/untrusted-checkout— the workflow checked out code at a ref sourced fromworkflow_runactions/code-injection(×6) —${{ env.TAG }}was populated fromgithub.event.workflow_run.head_branch, which is attacker-controlledAn attacker could create a branch named e.g.
v0.2.3; malicious-commandand trigger the release workflow, injecting into the tag resolution before validation ran.Fix
TAGfrom the job-levelenvblock entirelyresolve-tagstep that sources the tag from two trusted inputs only:inputs.tagfor manualworkflow_dispatch(privileged user input)workflow_runtriggers (data the repo owns)$GITHUB_OUTPUT${{ steps.resolve-tag.outputs.tag }}instead of${{ env.TAG }}Testing
workflow_dispatchwith a valid tag — confirm build and upload succeedSummary by CodeRabbit