ci(repo): replace labeler pull_request_target with workflow_run handshake#8859
ci(repo): replace labeler pull_request_target with workflow_run handshake#8859jacekradko wants to merge 2 commits into
Conversation
…hake The repo's only pull_request_target lived in labeler.yml. Split labeling into an untrusted trigger (pull_request, read-only, no secrets) that records the PR number to an artifact, and a privileged labeler-apply.yml (workflow_run) that validates the number, checks out only the trusted base .github/labeler.yml, and applies labels via actions/labeler driven by pr-number. Fork-PR labeling is preserved without the pull_request_target footgun. Refs SDK-80.
🦋 Changeset detectedLatest commit: fbb0b6b The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Repository UI (inherited) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe labeler GitHub Actions workflow is refactored from a single privileged ChangesLabeler Workflow Security Split
Sequence DiagramsequenceDiagram
participant PR as Pull Request (fork)
participant Collect as labeler.yml (collect)
participant Store as Artifact Store
participant Apply as labeler-apply.yml (apply)
participant Labeler as actions/labeler
PR->>Collect: pull_request event (no write token)
Collect->>Store: upload pr-number artifact
Store-->>Apply: workflow_run completed (success)
Apply->>Store: download pr-number artifact
Apply->>Apply: validate numeric PR number
Apply->>Apply: sparse checkout .github/labeler.yml
Apply->>Labeler: apply labels (pull-requests: write)
Labeler-->>PR: labels applied
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/expo
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
The PR number comes from the untrusted pull_request leg, so a malicious PR could upload another open PR's number and redirect the privileged labeler at it. Before labeling, verify via API that the claimed PR's head SHA and head repository match github.event.workflow_run (head_sha / head_repository), and fail closed otherwise. This preserves fork-PR labeling (workflow_run.pull_requests is empty for forks, so it can't be used for the binding). Refs SDK-80.
Removes the repo's only
pull_request_target(inlabeler.yml). Labeling is now a two-step handshake: an untrustedpull_requesttrigger that just writes the PR number to an artifact with no secrets and a read-only token, and a privilegedlabeler-apply.ymlonworkflow_runthat validates the number, sparse-checks-out only the trusted base.github/labeler.yml, and runsactions/labeler@v6withpr-number. Fork PRs keep getting labeled, which is the reasonpull_request_targetwas there in the first place.The piece worth a close look is the trust boundary in
labeler-apply.yml: it runs the base-branch copy of the workflow (PRs can't alter it), grantspull-requests: writeonly in that job, and never checks out PR-head code. The label rules in.github/labeler.ymlare unchanged.One caveat on verification:
workflow_runalways executes the default-branch version of a workflow, so the apply leg can't actually fire for PRs until this is onmain. On this PR you'll only see the "Labeler / Collect PR metadata" run upload the artifact; I'll confirm a same-repo PR gets labeled (then a fork PR) right after merge.Refs SDK-80.
Summary by CodeRabbit