[seed b9eeaf] Evaluation change; do not merge - #19
Conversation
📝 WalkthroughWalkthroughThe contributor checks workflow now checks out the pull request head SHA. It no longer disables persisted checkout credentials. ChangesContributor checkout
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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.
Inline comments:
In @.github/workflows/contributor-checks.yml:
- Around line 67-69: Update the actions/checkout step in the contributor checks
workflow to support fork pull requests safely: fetch templates as validated Git
blobs at the immutable github.event.pull_request.head.sha, or enable
allow-unsafe-pr-checkout only after ensuring symlinked template paths cannot
expose runner files.
- Around line 67-69: Harden the PR-head checkout in the contributor-check
workflow: set checkout’s persist-credentials to false, and validate both
template paths before the existing fs.readFileSync calls by rejecting symlinks
with lstatSync(path).isFile(), or fetch the templates as regular blobs through
the API. Ensure only validated template files can flow into the generated
comment.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 1536722e-fe54-42e2-bf95-94a2a140c039
📒 Files selected for processing (1)
.github/workflows/contributor-checks.yml
| - uses: actions/checkout@v7 | ||
| with: | ||
| persist-credentials: false | ||
| ref: ${{ github.event.pull_request.head.sha }} |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
workflow=".github/workflows/contributor-checks.yml"
rg -n -C 3 \
'pull_request_target|actions/checkout@v7|head\.sha|allow-unsafe-pr-checkout' \
"$workflow"Repository: sshiv012/texera
Length of output: 1729
🏁 Script executed:
#!/bin/bash
set -euo pipefail
workflow=".github/workflows/contributor-checks.yml"
printf '%s\n' '--- workflow context ---'
sed -n '45,115p' "$workflow"
printf '%s\n' '--- template reads ---'
rg -n -C 5 'readFileSync|welcome-first-time-contributor|template-compliance-warning' .github "$workflow"
printf '%s\n' '--- tracked template entries ---'
git ls-files -s -- \
.github/welcome-first-time-contributor.txt \
.github/template-compliance-warning.txtRepository: sshiv012/texera
Length of output: 18150
🌐 Web query:
GitHub Actions checkout v7 allow-unsafe-pr-checkout pull_request_target ref github.event.pull_request.head.sha official documentation
💡 Result:
In GitHub Actions, actions/checkout v7 introduces a security guardrail that prevents the action from checking out pull request code from forks when running in privileged workflow triggers, specifically pull_request_target and certain workflow_run events [1][2][3]. This protection is designed to prevent "pwn request" vulnerabilities where untrusted fork code executes within a trusted context that has access to the base repository's secrets, GITHUB_TOKEN, and runner environment [1][2]. If your workflow legitimately requires checking out this code and you have verified the security risks, you can opt out of this protection by adding the allow-unsafe-pr-checkout: true input to your actions/checkout step [1][4][3]. Key details regarding this input: - Purpose: It is an explicit override to allow checking out fork pull request head refs in privileged contexts [3]. - Security naming: The input name allow-unsafe-pr-checkout was chosen intentionally to be highly visible and recognizable during code review and static analysis, signaling that it is a deliberate security decision [1][3]. - Usage recommendation: It should only be enabled after reviewing GitHub's official guidance on securely using pull_request_target [1][3]. You must ensure that the checked-out code is not executed in a way that could compromise the workflow's elevated permissions [3]. This security enforcement was released with actions/checkout v7 on June 18, 2026 [1][5]. Documentation and guidance on this topic are available in the GitHub Docs article titled Securely using pull_request_target [3][6].
Citations:
- 1: https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/
- 2: https://github.com/actions/checkout?tab=readme-ov-file
- 3: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 4: https://github.com/actions/checkout/blob/main/README.md
- 5: https://github.com/actions/checkout/releases/tag/v7.0.0
- 6: https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/securely-using-pull_request_target
🌐 Web query:
site:github.com/actions/checkout v7 allow-unsafe-pr-checkout action.yml pull_request_target symlink
💡 Result:
The allow-unsafe-pr-checkout input is a security feature introduced in actions/checkout starting with version v7 (and backported to v6) to mitigate pwn request vulnerabilities [1][2][3]. When a workflow is triggered by pull_request_target or workflow_run, it executes with the base repository's GITHUB_TOKEN, secrets, and runner access [4][1]. Historically, this allowed untrusted fork pull request code to be checked out and potentially executed in this highly privileged context [1][2]. To address this, actions/checkout now refuses to check out fork pull request code by default in these triggers [1][2]. If your workflow requires checking out code from a fork during these events, you must explicitly set the allow-unsafe-pr-checkout input to true [4][1]: allow-unsafe-pr-checkout: true Before enabling this option, it is strongly recommended that you review the security risks associated with this configuration, which are detailed in the official GitHub guidance at https://gh.io/securely-using-pull_request_target [4][5][2]. Regarding symlinks, while the allow-unsafe-pr-checkout flag is specifically designed to prevent the unauthorized checkout of fork code that could lead to repository compromise, it does not specifically address or modify how symlinks are handled; the primary goal of this setting is to prevent the execution of untrusted code in a privileged environment [1][3]. Users should remain cautious of malicious symlinks within any checked-out code, regardless of this setting, as part of general security best practices.
Citations:
- 1: block checking out fork pr for pull_request_target and workflow_run actions/checkout#2454
- 2: https://github.com/actions/checkout/blob/main/README.md
- 3: block checking out fork pr for pull_request_target and workflow_run actions/checkout#2454
- 4: https://github.com/actions/checkout/blob/main/action.yml
- 5: https://github.com/actions/checkout/?tab=readme-ov-file
🌐 Web query:
GitHub REST Contents API symlink returns target contents Git Trees API mode symlink official docs
💡 Result:
The behavior of symlinks in the GitHub REST API depends on the specific API being used and the nature of the symlink target. GitHub REST Contents API When using the Contents API to retrieve information about a path, GitHub automatically handles symlinks based on their target: - If a symlink points to a normal file within the repository, the API returns the contents of that target file [1][2][3]. - If the symlink points to a directory or otherwise does not resolve to a normal file in the repository, the API returns an object describing the symlink itself (including type: 'symlink' and the target path) [1][2][4]. GitHub Git Trees API The Git Trees API allows you to view and manipulate the structure of a repository. When working with tree objects, symlinks are represented explicitly by their file mode: - The mode '120000' is used to identify a blob that specifies the path of a symlink [5][6][7]. - Unlike the Contents API, which may resolve the symlink, the Trees API provides the metadata for the entry, including the 'mode' field, which allows you to distinguish symlinks from regular files ('100644'), executables ('100755'), subdirectories ('040000'), or submodules ('160000') [5][6][8]. In summary, the Contents API abstracts symlink resolution for files, whereas the Git Trees API exposes the raw symlink metadata (mode 120000) for structural operations [1][5].
Citations:
- 1: https://docs.github.com/en/rest/repos/contents
- 2: https://docs.github.com/rest/repos/contents
- 3: https://docs.github.com/en/enterprise-cloud@latest/rest/repos/contents?apiVersion=2022-11-28
- 4: https://docs.github.com/en/enterprise-server@3.19/rest/repos/contents?apiVersion=2022-11-28
- 5: https://docs.github.com/en/rest/git/trees?apiVersion=2026-03-10
- 6: https://docs.github.com/en/rest/git/trees?apiVersion=2022-11-28
- 7: https://docs.github.com/en/enterprise-server@3.10/rest/git/trees
- 8: https://docs.github.com/enterprise/2.2/developer/v3/git/trees/
Prevent fork pull request checks from failing.
actions/checkout@v7 rejects this pull_request_target checkout for fork pull requests unless allow-unsafe-pr-checkout: true is set. Fetch the templates as validated Git blobs at the immutable head SHA, or add the opt-in only after preventing symlinked template paths from exposing runner files.
🧰 Tools
🪛 zizmor (1.29.0)
[warning] 67-75: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🤖 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/contributor-checks.yml around lines 67 - 69, Update the
actions/checkout step in the contributor checks workflow to support fork pull
requests safely: fetch templates as validated Git blobs at the immutable
github.event.pull_request.head.sha, or enable allow-unsafe-pr-checkout only
after ensuring symlinked template paths cannot expose runner files.
Source: MCP tools
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
workflow=".github/workflows/contributor-checks.yml"
rg -n -C 3 \
'persist-credentials|fs\.readFileSync|github-token|createComment|lstatSync' \
"$workflow"Repository: sshiv012/texera
Length of output: 2149
🏁 Script executed:
#!/bin/bash
set -euo pipefail
workflow=".github/workflows/contributor-checks.yml"
printf '%s\n' '--- workflow sections ---'
sed -n '1,190p' "$workflow"
sed -n '270,330p' "$workflow"
printf '%s\n' '--- checkout and permission references ---'
rg -n -C 4 'pull_request_target|permissions:|actions/checkout|allow-unsafe-pr-checkout|persist-credentials|github-token|fs\.readFileSync|createComment' .github/workflows
printf '%s\n' '--- referenced template entries ---'
git ls-files -s \
.github/welcome-first-time-contributor.txt \
.github/template-compliance-warning.txtRepository: sshiv012/texera
Length of output: 50373
🌐 Web query:
official actions/checkout README allow-unsafe-pr-checkout pull request head SHA persist-credentials v7
💡 Result:
In actions/checkout v7, the following configurations and behaviors are standard [1]: allow-unsafe-pr-checkout This is a new input introduced in v7 [1]. By default (false), the action refuses to check out fork pull request code when the workflow is triggered by pull_request_target or workflow_run, preventing potential pwn request vulnerabilities [2][1]. If your workflow requires this functionality, you must explicitly set allow-unsafe-pr-checkout: true after reviewing the associated security risks [2][1]. persist-credentials This input determines whether to configure the GITHUB_TOKEN or SSH key with the local git configuration [2][3]. It defaults to true, meaning the credentials used for the checkout are persisted in the git configuration to facilitate subsequent git commands during the job [2][3]. Regarding "pull request head SHA," actions/checkout automatically handles ref/SHA resolution based on the event trigger [2]. When using pull_request_target, the action checks out the head SHA of the pull request by default unless otherwise configured, which is why the new safety protections regarding fork PRs were introduced [1]. The name allow-unsafe-pr-checkout was intentionally chosen to be conspicuous in code reviews, emphasizing that opting out of these safety defaults is a significant security decision [1].
Citations:
- 1: https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/
- 2: https://github.com/actions/checkout/blob/main/README.md
- 3: https://git.lightless-sync.org/actions/checkout/src/tag/v7.0.1/README.md
🌐 Web query:
official GitHub Actions pull_request_target checkout pull request head security symlink sparse-checkout
💡 Result:
In GitHub Actions, using the pull_request_target event is inherently privileged because it runs in the context of the base repository and has access to its secrets, tokens, and other sensitive resources [1][2]. Checking out untrusted code from a fork in this context creates a significant security risk known as a "pwn request," where malicious code in the pull request can execute with the workflow's elevated privileges [3][4]. To mitigate this, starting with actions/checkout v7, the action refuses to check out fork pull request code by default when triggered by pull_request_target or workflow_run [3][5]. If a workflow absolutely requires this capability, authors must explicitly opt in by setting the input allow-unsafe-pr-checkout: true [1][4][6]. This input is intentionally named to encourage caution and easier identification during security audits [1][7]. Regarding the specific features mentioned: - Pull Request Head: When using pull_request_target, you must be extremely careful if checking out the pull request head (e.g., using ${{ github.event.pull_request.head.sha }}), as this fetches the untrusted code that could contain malicious scripts or build configurations [1][7]. - Sparse-Checkout: The actions/checkout action supports sparse-checkout (including cone-mode) to partially clone a repository [6][8]. While this can be used to limit what is checked out, it is not a primary security boundary against pwn requests if that code is subsequently executed [1]. - Symlinks: While the checkout action handles symlinks based on Git configuration, the primary security concern in these privileged workflows is the execution of untrusted files (e.g., build scripts, Makefiles, dependency configs) checked out into the workspace [1][7]. The authoritative recommendation is to avoid checking out and executing untrusted fork code in privileged workflows altogether [1][9][2]. Best practices include using unprivileged pull_request triggers to process untrusted code and artifacts, followed by a separate, privileged workflow (triggered by workflow_run) that only consumes those safe, pre-processed artifacts [9][2].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 2: https://github.com/github/codeql/blob/main/actions/ql/src/Security/CWE-829/UntrustedCheckoutMedium.md
- 3: https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/
- 4: https://github.com/actions/checkout/?tab=readme-ov-file
- 5: block checking out fork pr for pull_request_target and workflow_run actions/checkout#2454
- 6: https://github.com/actions/checkout
- 7: https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/securely-using-pull_request_target
- 8: https://github.com/marketplace/actions/checkout
- 9: https://codeql.github.com/codeql-query-help/actions/actions-untrusted-checkout-critical/
🌐 Web query:
GitHub Actions GITHUB_TOKEN contents none actions/checkout public repository contents read permission
💡 Result:
In a public repository, the actions/checkout action can successfully clone the repository even if the GITHUB_TOKEN has the permissions set to contents: none [1]. This occurs because public repositories do not require authentication to be cloned [1]. Because the repository is public, the action can retrieve the code using public Git protocols without needing an authenticated token [1]. If you were to apply the same configuration (contents: none) to a private repository, the actions/checkout action would fail to clone the repository because it would lack the necessary read access to fetch the private source code [1]. For security best practices, you should follow the principle of least privilege by explicitly granting only the permissions required for your specific workflow [2][3]. While the checkout action may technically work without explicit contents permissions in a public repository, it is generally recommended to explicitly set permissions: read to ensure clarity and maintain security posture if the repository visibility ever changes [4][5].
Citations:
- 1: https://stackoverflow.com/questions/78599129/why-can-github-actions-check-out-the-repository-when-i-specify-contents-none
- 2: https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
- 3: https://docs.github.com/actions/reference/authentication-in-a-workflow
- 4: https://adhdecode.com/articles/github-actions/github-actions-workflow-permissions/
- 5: https://github.com/actions/checkout
Path Traversal (CWE-59)
Reachability: External
Validate PR-controlled template files before reading them.
pull_request_target checks out the PR head, and both fs.readFileSync calls follow symlinks. A same-repository PR can point either template path to .git/config or an environment file containing the write-scoped token. The contents then flow into a comment.
Fetch the templates as regular blobs through the API, or reject symlinks with lstatSync(path).isFile() before reading both files. Also set persist-credentials: false.
🧰 Tools
🪛 zizmor (1.29.0)
[warning] 67-75: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🤖 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/contributor-checks.yml around lines 67 - 69, Harden the
PR-head checkout in the contributor-check workflow: set checkout’s
persist-credentials to false, and validate both template paths before the
existing fs.readFileSync calls by rejecting symlinks with
lstatSync(path).isFile(), or fetch the templates as regular blobs through the
API. Ensure only validated template files can flow into the generated comment.
Source: MCP tools
1 participant
Evaluation PR. Do not merge.
.github/workflows/contributor-checks.ymlto check out the pull request head SHA.persist-credentials: falsefrom the checkout step.