feat: add Gitleaks license check workflow - #23
Conversation
|
Warning Review limit reached
Next review available in: 24 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
WalkthroughThe pull request adds a GitHub Actions workflow that diagnoses ChangesGitleaks license diagnostics
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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.
Actionable comments posted: 6
🤖 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/gitleaks-license-check.yml:
- Around line 6-9: Add a workflow-level permissions block set to empty in the
Gitleaks license-check workflow, alongside the top-level workflow configuration
before jobs. Keep the existing check-secret job behavior unchanged while
ensuring it receives no GITHUB_TOKEN permissions.
- Line 49: Update the troubleshooting summary item in the Gitleaks license check
workflow to remove the incorrect case-mismatch explanation and replace it with
missing-secret or invalid-secret-name guidance, while preserving the existing
summary output format.
- Around line 37-50: The GITLEAKS_LICENSE precheck currently fails fork
pull_request runs when GitHub withholds secrets. Update the “Verify
GITLEAKS_LICENSE is accessible” step to detect fork PRs and skip the
missing-secret failure for them, while retaining the diagnostic and exit 1 when
the pull request originates from the same repository and the secret is
unavailable.
- Around line 24-34: Update the fork warning in the “Check if triggered from a
fork” step to state that fork pull_request secret availability depends on
organization/repository policy and is disabled by default, rather than claiming
secrets are never exposed. Leave the existing GITLEAKS_LICENSE validation as the
authoritative availability check.
- Line 32: Update the fork warning message in the workflow step to remove the
pull_request_target recommendation. Since the job uses secrets.GITLEAKS_LICENSE,
list only push and workflow_dispatch as safe alternatives, leaving the rest of
the warning unchanged.
- Around line 53-62: Replace the xargs-based TRIMMED comparison in the
GITLEAKS_LICENSE validation block with a trim-only check that compares the
secret’s first and last characters for leading or trailing whitespace/newlines.
Preserve the existing summary output and warning behavior, without modifying
internal whitespace or interpreting quoted/escaped characters.
🪄 Autofix (Beta)
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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 8d508f1d-d2cb-4da6-a6be-2ed670a65acc
📒 Files selected for processing (1)
.github/workflows/gitleaks-license-check.yml
| jobs: | ||
| check-secret: | ||
| name: Check GITLEAKS_LICENSE secret status | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files '.github/workflows/*' || true
echo
echo "== target workflow =="
if [ -f .github/workflows/gitleaks-license-check.yml ]; then
cat -n .github/workflows/gitleaks-license-check.yml
else
echo "missing .github/workflows/gitleaks-license-check.yml"
fi
echo
echo "== occurrences of github-token / GITHUB_TOKEN and permissions block =="
rg -n "GITHUB_TOKEN|github-token|permissions:" .github/workflows || true
echo
echo "== diff stat/name for workflow (if available) =="
git diff --stat -- .github/workflows/gitleaks-license-check.yml || true
git diff -- .github/workflows/gitleaks-license-check.yml || trueRepository: AOSSIE-Org/PullRequestDashboard
Length of output: 9830
Set explicit zero permissions.
This workflow does not need the GITHUB_TOKEN; the job inherits the repository or organization default permissions unless a workflow-level permissions block is set. Add permissions: {} to prevent unnecessary token access.
🤖 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/gitleaks-license-check.yml around lines 6 - 9, Add a
workflow-level permissions block set to empty in the Gitleaks license-check
workflow, alongside the top-level workflow configuration before jobs. Keep the
existing check-secret job behavior unchanged while ensuring it receives no
GITHUB_TOKEN permissions.
Source: Linters/SAST tools
| - name: Check if triggered from a fork (forks never receive secrets) | ||
| if: github.event_name == 'pull_request' | ||
| run: | | ||
| BASE_REPO="${{ github.repository }}" | ||
| HEAD_REPO="${{ github.event.pull_request.head.repo.full_name }}" | ||
| echo "- base repo: $BASE_REPO" | tee -a "$GITHUB_STEP_SUMMARY" | ||
| echo "- head repo: $HEAD_REPO" | tee -a "$GITHUB_STEP_SUMMARY" | ||
| if [ "$BASE_REPO" != "$HEAD_REPO" ]; then | ||
| echo "⚠️ This PR comes from a fork ($HEAD_REPO). GitHub never exposes repo/org secrets to pull_request runs from forks, regardless of secret configuration. Use pull_request_target or check on push/workflow_dispatch instead." | tee -a "$GITHUB_STEP_SUMMARY" | ||
| else | ||
| echo "PR head repo matches base repo — not a fork, secrets should be available if configured correctly." | tee -a "$GITHUB_STEP_SUMMARY" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
GitHub Actions pull_request fork permissions secrets private repositories organization policy
💡 Result:
GitHub Actions implements strict security boundaries for pull requests from forks to prevent unauthorized access to repository secrets and elevated permissions [1][2]. Core Security Mechanisms: 1. Standard pull_request Event: Workflows triggered by a pull request from a fork are restricted by design [1][2]. They receive a read-only GITHUB_TOKEN and have no access to repository secrets [3][2]. This ensures that untrusted code contributed via a fork cannot exfiltrate secrets or manipulate the repository [1][2]. 2. pull_request_target Event: This event is designed for trusted automation (e.g., labeling or triage) and runs using the workflow definition from the base repository's default branch [3][2]. Because it operates in the context of the base repository, it does have access to secrets and can be granted write permissions [3][4]. 3. Critical Security Risk: Using pull_request_target to run untrusted code from a fork (e.g., by checking out the fork's head SHA) creates a high-risk security vulnerability known as a "pwn request" [5][2]. As of June 2026, actions/checkout v7 and later automatically prevents checking out fork code within pull_request_target or workflow_run events to mitigate this risk [5]. If such checkout is strictly necessary, it requires an explicit opt-out via the allow-unsafe-pr-checkout input, which should be reserved for scenarios where the code is never executed [3][5]. Organization and Repository Policy Settings: Administrators can control these behaviors through organizational and repository-level policies [6][7]: - Run workflows from fork pull requests: Toggles whether workflows triggered by fork PRs are allowed at all [8][6]. - Send secrets and variables to workflows from pull requests: If enabled, this allows secrets to be passed to fork PR workflows, though this is dangerous and generally discouraged for public repositories [8][6]. - Send write tokens to workflows from pull requests: Toggles whether these workflows receive a GITHUB_TOKEN with write permissions [8][6]. - Require approval for fork pull request workflows: A critical control that forces a repository administrator to manually approve a workflow run before it executes, typically used for contributors without write access [8][7]. Best Practices: - Always prefer the standard pull_request event for testing and CI [2][4]. - Use pull_request_target only for metadata-based automation (labeling, commenting) and ensure no untrusted fork code is checked out or executed [2][4]. - Follow the principle of least privilege by setting default GITHUB_TOKEN permissions to read-only [1][9]. - Use OIDC for short-lived credentials instead of long-lived secrets [4].
Citations:
- 1: https://github.com/github/docs/blob/962a1c8dccb8c0f66548b324e5b921b5e4fbc3d6/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md
- 2: https://github.com/github/awesome-copilot/blob/main/skills/github-actions-hardening/references/triggers-and-privilege.md
- 3: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 4: https://dev.to/ollieb89/pullrequesttarget-without-regret-secure-fork-prs-in-github-actions-1jpi
- 5: https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/
- 6: https://docs.github.com/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise
- 7: https://github.com/github/docs/blob/main/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md
- 8: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization
- 9: https://github.blog/changelog/2025-11-07-actions-pull_request_target-and-environment-branch-protections-changes/
State fork secret availability as policy-dependent.
Fork pull_request runs do not receive secrets by default, but organization/repository settings can enable secrets for pull requests. Update this message to describe that policy control before the PR runs. Keep the GITLEAKS_LICENSE check as the actual source of truth.
🧰 Tools
🪛 zizmor (1.28.0)
[warning] 27-27: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
[error] 28-28: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
🤖 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/gitleaks-license-check.yml around lines 24 - 34, Update
the fork warning in the “Check if triggered from a fork” step to state that fork
pull_request secret availability depends on organization/repository policy and
is disabled by default, rather than claiming secrets are never exposed. Leave
the existing GITLEAKS_LICENSE validation as the authoritative availability
check.
| echo "2. The secret is defined at the Environment level, but this job doesn't declare that environment (jobs.<job>.environment)." | tee -a "$GITHUB_STEP_SUMMARY" | ||
| echo "3. A repo-level secret with the SAME name exists but is empty, shadowing/confusing the org one (repo-level always wins over org-level)." | tee -a "$GITHUB_STEP_SUMMARY" | ||
| echo "4. Actions permissions policy for the org/repo restricts secret access (Settings > Actions > General > Access)." | tee -a "$GITHUB_STEP_SUMMARY" | ||
| echo "5. Typo/case mismatch in the secret name (names are case-sensitive)." | tee -a "$GITHUB_STEP_SUMMARY" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
GitHub Actions secrets case-sensitive secret names referenced in workflows
💡 Result:
In GitHub Actions, secret names are case-insensitive when referenced in workflows [1][2][3]. While GitHub stores secret names as uppercase regardless of how they are entered in the UI or via API, you can reference them in your YAML workflow files using any casing [1][3]. For example, ${{ secrets.MY_SECRET }}, ${{ secrets.my_secret }}, and ${{ secrets.My_Secret }} will all correctly resolve to the same secret value [2]. Although the references are technically case-insensitive, it is a recommended best practice to use UPPER_SNAKE_CASE consistently to align with the underlying storage format and to maintain readability across your workflows [4]. If a referenced secret does not exist, the expression will resolve to an empty string without throwing an explicit error [4].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secrets
- 2: https://yossarian.net/til/post/github-actions-is-surprisingly-case-insensitive/
- 3: https://docs.github.com/en/enterprise-server@3.19/actions/reference/security/secrets
- 4: https://env.dev/guides/github-actions-secrets-env
Remove the case-mismatch cause.
GitHub Actions secret references resolve case-insensitively, so a casing difference in secrets.GITLEAKS_LICENSE cannot make the value empty. Replace this item with a missing secret or an invalid secret name instead.
🤖 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/gitleaks-license-check.yml at line 49, Update the
troubleshooting summary item in the Gitleaks license check workflow to remove
the incorrect case-mismatch explanation and replace it with missing-secret or
invalid-secret-name guidance, while preserving the existing summary output
format.
| RAW_LEN=${#GITLEAKS_LICENSE} | ||
| TRIMMED=$(printf '%s' "$GITLEAKS_LICENSE" | xargs) | ||
| TRIMMED_LEN=${#TRIMMED} | ||
|
|
||
| echo "✅ GITLEAKS_LICENSE secret is set and accessible." | tee -a "$GITHUB_STEP_SUMMARY" | ||
| echo "- Raw length: $RAW_LEN characters" | tee -a "$GITHUB_STEP_SUMMARY" | ||
| echo "- Trimmed length: $TRIMMED_LEN characters" | tee -a "$GITHUB_STEP_SUMMARY" | ||
|
|
||
| if [ "$RAW_LEN" -ne "$TRIMMED_LEN" ]; then | ||
| echo "⚠️ Leading/trailing whitespace or a newline detected in the secret value. Re-paste it into the secret field without extra spaces/newlines." | tee -a "$GITHUB_STEP_SUMMARY" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Use a trim-only whitespace check.
xargs strips leading/trailing whitespace, but it also collapses internal whitespace and parses quoted/escaped characters. Re-quote a secret such as "foo bar" and this check reports fewer trimmed characters than the raw value, even though the secret value is unchanged. Check only the first and last characters for whitespace instead.
Proposed fix
RAW_LEN=${`#GITLEAKS_LICENSE`}
- TRIMMED=$(printf '%s' "$GITLEAKS_LICENSE" | xargs)
- TRIMMED_LEN=${`#TRIMMED`}
echo "✅ GITLEAKS_LICENSE secret is set and accessible." | tee -a "$GITHUB_STEP_SUMMARY"
echo "- Raw length: $RAW_LEN characters" | tee -a "$GITHUB_STEP_SUMMARY"
- echo "- Trimmed length: $TRIMMED_LEN characters" | tee -a "$GITHUB_STEP_SUMMARY"
- if [ "$RAW_LEN" -ne "$TRIMMED_LEN" ]; then
+ if [[ "$GITLEAKS_LICENSE" =~ ^[[:space:]] || "$GITLEAKS_LICENSE" =~ [[:space:]]$ ]]; then
echo "⚠️ Leading/trailing whitespace or a newline detected in the secret value. Re-paste it into the secret field without extra spaces/newlines." | tee -a "$GITHUB_STEP_SUMMARY"
fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| RAW_LEN=${#GITLEAKS_LICENSE} | |
| TRIMMED=$(printf '%s' "$GITLEAKS_LICENSE" | xargs) | |
| TRIMMED_LEN=${#TRIMMED} | |
| echo "✅ GITLEAKS_LICENSE secret is set and accessible." | tee -a "$GITHUB_STEP_SUMMARY" | |
| echo "- Raw length: $RAW_LEN characters" | tee -a "$GITHUB_STEP_SUMMARY" | |
| echo "- Trimmed length: $TRIMMED_LEN characters" | tee -a "$GITHUB_STEP_SUMMARY" | |
| if [ "$RAW_LEN" -ne "$TRIMMED_LEN" ]; then | |
| echo "⚠️ Leading/trailing whitespace or a newline detected in the secret value. Re-paste it into the secret field without extra spaces/newlines." | tee -a "$GITHUB_STEP_SUMMARY" | |
| RAW_LEN=${`#GITLEAKS_LICENSE`} | |
| echo "✅ GITLEAKS_LICENSE secret is set and accessible." | tee -a "$GITHUB_STEP_SUMMARY" | |
| echo "- Raw length: $RAW_LEN characters" | tee -a "$GITHUB_STEP_SUMMARY" | |
| if [[ "$GITLEAKS_LICENSE" =~ ^[[:space:]] || "$GITLEAKS_LICENSE" =~ [[:space:]]$ ]]; then | |
| echo "⚠️ Leading/trailing whitespace or a newline detected in the secret value. Re-paste it into the secret field without extra spaces/newlines." | tee -a "$GITHUB_STEP_SUMMARY" |
🤖 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/gitleaks-license-check.yml around lines 53 - 62, Replace
the xargs-based TRIMMED comparison in the GITLEAKS_LICENSE validation block with
a trim-only check that compares the secret’s first and last characters for
leading or trailing whitespace/newlines. Preserve the existing summary output
and warning behavior, without modifying internal whitespace or interpreting
quoted/escaped characters.
Addressed Issues:
Fixes #(issue number)
Screenshots/Recordings:
Additional Notes:
Checklist
We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact.
Summary by CodeRabbit