Fix/int 1582/fix lint context + upgrade trunk-action#2
Conversation
📝 WalkthroughWalkthroughThe lint reusable workflow adds a required ChangesLint Workflow Reusable Input
Possibly Related PRs
Suggested Reviewers
Poem
🎯 2 (Simple) | ⏱️ ~5-10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/lint.yaml (1)
27-34:⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy liftAvoid linting PR-controlled refs under a
pull_request_targettrust boundary.Checking out
${{ inputs.head-ref }}and then running Trunk with${{ secrets.GITHUB_TOKEN }}executes PR-authored code/config with repository-token privileges. Given this is intended to be called frompull_request_target, this is a privilege-escalation risk for untrusted PRs.Use
pull_requestfor PR-ref linting, or split trusted/untrusted paths so no secrets or write-capable token are exposed when linting PR code.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/lint.yaml around lines 27 - 34, The workflow currently checks out `${{ inputs.head-ref }}` and runs the "Trunk Check" step using the trunk-io/trunk-action with `GITHUB_TOKEN` which exposes a write-capable secret when this job is invoked under a `pull_request_target` trust boundary; change the workflow to avoid running untrusted PR code with secrets by either switching PR linting to run under the `pull_request` event (so `${{ inputs.head-ref }}` runs without elevated tokens) or by splitting the job into trusted vs untrusted paths: keep the trunk-io/trunk-action step that uses `GITHUB_TOKEN` only on trusted events (e.g., `pull_request_target` comparing repository refs) and create a separate untrusted Trunk step for PRs that does not pass `GITHUB_TOKEN` (or uses a read-only token) and does not check out PR-controlled refs, ensuring the `Trunk Check` step and use of `GITHUB_TOKEN` are only present in trusted workflows.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/lint.yaml:
- Around line 27-34: The workflow currently checks out `${{ inputs.head-ref }}`
and runs the "Trunk Check" step using the trunk-io/trunk-action with
`GITHUB_TOKEN` which exposes a write-capable secret when this job is invoked
under a `pull_request_target` trust boundary; change the workflow to avoid
running untrusted PR code with secrets by either switching PR linting to run
under the `pull_request` event (so `${{ inputs.head-ref }}` runs without
elevated tokens) or by splitting the job into trusted vs untrusted paths: keep
the trunk-io/trunk-action step that uses `GITHUB_TOKEN` only on trusted events
(e.g., `pull_request_target` comparing repository refs) and create a separate
untrusted Trunk step for PRs that does not pass `GITHUB_TOKEN` (or uses a
read-only token) and does not check out PR-controlled refs, ensuring the `Trunk
Check` step and use of `GITHUB_TOKEN` are only present in trusted workflows.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: c4c6efaf-358e-4359-a80b-a8eb9fed547d
📒 Files selected for processing (2)
.github/workflows/lint.yaml.github/workflows/tf-test.yaml
what
head-refas an input to our lint workflowtrunk-io/trunk-actionto 1.3.1why
pull_request_target, the workflow is currently checking out the code in main and not linting on the changes being added in the feature branch. Usinghead-refwill fix this.head-refwill be defined as${{ format('refs/pull/{0}/merge', github.event.number) }}tf-test.yaml, because "test" is very generic and I know of at least one example where we use the same name for a workflow file that does testing that is not terraform related. Since this is a centralized workflow file, it makes sense to make the name more specific.trunk-action. The newer version includes contributions from our very own @Xeboc. It's a very important contribution to Pin GitHub Actions to full commit SHAs, which is going to be good for our overall security posture here as well.references