build: apply zizmor recommended fixes#2764
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughAdds explicit workflow permissions, pins GitHub Actions to specific commit SHAs across CI workflows, refactors Slack failure outcome handling, updates cache/checkout settings, adds a new zizmor security analysis workflow, and sets a 7-day Dependabot cooldown. ChangesGitHub Actions and Dependabot Security Hardening
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
@blocknote/ariakit
@blocknote/code-block
@blocknote/core
@blocknote/mantine
@blocknote/react
@blocknote/server-util
@blocknote/shadcn
@blocknote/xl-ai
@blocknote/xl-docx-exporter
@blocknote/xl-email-exporter
@blocknote/xl-multi-column
@blocknote/xl-odt-exporter
@blocknote/xl-pdf-exporter
commit: |
![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 current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/relative-ci.yaml:
- Around line 4-5: The workflow currently runs on workflow_run for all completed
build runs and unconditionally supplies secrets.RELATIVE_CI_KEY and
secrets.GITHUB_TOKEN to relative-ci/agent-action; add a trust boundary by gating
the job (or the step that uses relative-ci/agent-action and the secrets) with an
if condition that checks github.event.workflow_run.workflow.name == 'build' AND
github.event.workflow_run.conclusion == 'success' AND
github.event.workflow_run.event == 'push' (or another trusted event), so the
secrets are only passed when the originating build run is a successful trusted
push build.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 461fec09-061e-417f-8c57-d66dbe03aba7
📒 Files selected for processing (5)
.github/dependabot.yml.github/workflows/build.yml.github/workflows/fresh-install-tests.yml.github/workflows/publish.yaml.github/workflows/relative-ci.yaml
| # zizmor: ignore[dangerous-triggers] -- workflow_run is the recommended pattern | ||
| # for RelativeCI; this workflow only downloads artifacts and reports bundle stats. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Check upstream trigger includes pull_request:"
rg -n -C2 '^\s*pull_request:' .github/workflows/build.yml
echo
echo "Check downstream workflow_run and trust guard presence:"
rg -n -C3 'workflow_run:|github\.event\.workflow_run\.event|github\.event\.workflow_run\.conclusion' .github/workflows/relative-ci.yaml
echo
echo "Check downstream job uses secrets:"
rg -n -C2 'secrets\.RELATIVE_CI_KEY|secrets\.GITHUB_TOKEN' .github/workflows/relative-ci.yamlRepository: TypeCellOS/BlockNote
Length of output: 733
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== relative-ci.yaml ==="
nl -ba .github/workflows/relative-ci.yaml | sed -n '1,200p'
echo
echo "=== build.yml (trigger section) ==="
nl -ba .github/workflows/build.yml | sed -n '1,120p'Repository: TypeCellOS/BlockNote
Length of output: 150
🌐 Web query:
GitHub Actions workflow_run triggered by pull_request whether downstream workflow gets secrets and how permissions/security context works
💡 Result:
Downstream workflow permissions/secrets behavior when using on: workflow_run after a pull_request 1) Does the downstream workflow get repository secrets? - Yes: a workflow started by workflow_run “is able to access secrets and write tokens, even if the previous workflow was not.” [1][2] - Practical implication: if the upstream workflow was triggered by pull_request (including from a fork), and the downstream is triggered via workflow_run, the downstream runs with elevated access (i.e., it can access repository secrets), which is why workflow_run can be security-sensitive. [1][2] 2) Does the upstream pull_request workflow have access to secrets? - Generally, for pull_request from a fork, GitHub prevents secret passing: “With the exception of GITHUB_TOKEN, secrets are not passed … when a workflow is triggered from a forked repository. The GITHUB_TOKEN has read-only permissions in pull requests from forked repositories.” [1] 3) What’s special about GITHUB_TOKEN in this context? - GITHUB_TOKEN is always included in the secrets context for any workflow run (i.e., it exists as secrets.GITHUB_TOKEN / github.token). [3] - The key nuance is its permissions: for fork-based pull_request, GITHUB_TOKEN is read-only; for workflow_run, GitHub states the workflow_run-triggered workflow can write tokens and access secrets. [1][2][3] 4) Security context / where the code runs (why this matters) - pull_request executes in a way that prevents running unsafe code from the pull request head with access to secrets (it “prevents execution of unsafe code from the head … that could … steal any secrets you use in your workflow”). [4] - workflow_run is explicitly described as able to access secrets and write tokens, even when the prior workflow was not privileged. [2] - Therefore, the security context can “escalate” on the workflow_run hop: downstream code (or steps) can run in a privileged context with secrets, even if the upstream was unprivileged due to fork restrictions. [1][2] 5) How permissions/security should be configured - Always restrict GITHUB_TOKEN permissions explicitly with the permissions key (least privilege). [1][5] - Additionally, treat workflow_run as privileged: avoid checking out/building untrusted PR code directly in the workflow_run workflow, and gate privileged actions based on what triggered the run (e.g., only proceed for trusted events/branches), because untrusted input can be used to poison artifacts that the downstream consumes. [1][2] Answering your exact question succinctly - If your downstream workflow is triggered via on: workflow_run after an upstream pull_request, the downstream workflow can access repository secrets and write tokens, even if the upstream pull_request workflow didn’t. [1][2] - The upstream pull_request workflow (from forks) does not get secrets (except GITHUB_TOKEN, with read-only permissions). [1] - The permissions/security context is therefore not “inherited as unprivileged”; workflow_run creates a privileged second stage. [1][2]
Citations:
- 1: https://docs.github.com/actions/using-workflows/events-that-trigger-workflows
- 2: https://raw.githubusercontent.com/github/docs/refs/heads/main/content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md
- 3: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/contexts.md
- 4: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md
- 5: https://github.com/github/docs/blob/main/content/actions/concepts/security/compromised-runners.md
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== relative-ci.yaml (show full file if small) ==="
wc -l .github/workflows/relative-ci.yaml
sed -n '1,200p' .github/workflows/relative-ci.yaml | cat -n
echo
echo "=== build.yml (show trigger section) ==="
wc -l .github/workflows/build.yml
sed -n '1,120p' .github/workflows/build.yml | cat -nRepository: TypeCellOS/BlockNote
Length of output: 5622
Gate RelativeCI’s workflow_run on trusted build runs before using repository secrets.
relative-ci.yaml triggers on workflow_run for all completed build runs (including those originating from pull_request) with no guard on github.event.workflow_run.event/conclusion, and then passes secrets.RELATIVE_CI_KEY and secrets.GITHUB_TOKEN into relative-ci/agent-action. The zizmor dangerous-triggers ignore comment doesn’t create a trust boundary.
Suggested patch
jobs:
build:
+ if: ${{ github.event.workflow_run.conclusion == 'success' && github.event.workflow_run.event == 'push' }}
runs-on: ubuntu-latest
steps:
- name: Send bundle stats and build information to RelativeCI (editor)
uses: relative-ci/agent-action@38328454d6a23942175eba485fca4fbb807b1f03 # v2🤖 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/relative-ci.yaml around lines 4 - 5, The workflow
currently runs on workflow_run for all completed build runs and unconditionally
supplies secrets.RELATIVE_CI_KEY and secrets.GITHUB_TOKEN to
relative-ci/agent-action; add a trust boundary by gating the job (or the step
that uses relative-ci/agent-action and the secrets) with an if condition that
checks github.event.workflow_run.workflow.name == 'build' AND
github.event.workflow_run.conclusion == 'success' AND
github.event.workflow_run.event == 'push' (or another trusted event), so the
secrets are only passed when the originating build run is a successful trusted
push build.
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/relative-ci.yaml (1)
18-18:⚠️ Potential issue | 🟠 Major | ⚡ Quick winKeep the trust boundary in the
workflow_runguard.Line 18 only filters on
conclusion, so a successfulpull_request-originatedbuildrun can still reach the secret-bearingrelative-ci/agent-actionstep below. Add a trusted event check (push, or whatever source you explicitly trust) before handing overRELATIVE_CI_KEYandGITHUB_TOKEN.Suggested patch
- if: github.event.workflow_run.conclusion == 'success' + if: >- + ${{ + github.event.workflow_run.conclusion == 'success' && + github.event.workflow_run.event == 'push' + }}Expected result: if the upstream
buildworkflow still runs onpull_request, this check confirms the current guard is still too broad.#!/bin/bash set -euo pipefail echo "=== relative-ci.yaml ===" nl -ba .github/workflows/relative-ci.yaml | sed -n '1,80p' echo echo "=== build workflow triggers ===" build_file="$(fd -p '^build\.yml$' .github/workflows | head -n1)" nl -ba "$build_file" | sed -n '1,80p' echo echo "=== focused checks ===" rg -n -C2 '^\s*pull_request:|^\s*push:' "$build_file" rg -n -C2 'workflow_run\.conclusion|workflow_run\.event|RELATIVE_CI_KEY|GITHUB_TOKEN' .github/workflows/relative-ci.yaml🤖 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/relative-ci.yaml at line 18, The current workflow_run guard only checks "if: github.event.workflow_run.conclusion == 'success'" which allows runs triggered by untrusted events (e.g., pull_request) to reach the secret-bearing relative-ci/agent-action step and expose RELATIVE_CI_KEY and GITHUB_TOKEN; tighten the guard by adding an explicit trusted-event check (for example: require github.event.workflow_run.event == 'push' or another event you trust) so the if becomes a conjunction of conclusion and event, or otherwise verify github.event.workflow_run.head_repository.owner matches the trusted owner before passing secrets to the relative-ci/agent-action step.
🤖 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.
Duplicate comments:
In @.github/workflows/relative-ci.yaml:
- Line 18: The current workflow_run guard only checks "if:
github.event.workflow_run.conclusion == 'success'" which allows runs triggered
by untrusted events (e.g., pull_request) to reach the secret-bearing
relative-ci/agent-action step and expose RELATIVE_CI_KEY and GITHUB_TOKEN;
tighten the guard by adding an explicit trusted-event check (for example:
require github.event.workflow_run.event == 'push' or another event you trust) so
the if becomes a conjunction of conclusion and event, or otherwise verify
github.event.workflow_run.head_repository.owner matches the trusted owner before
passing secrets to the relative-ci/agent-action step.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c04f7a1b-14f6-4697-93e8-4f48d5a3fdf2
📒 Files selected for processing (1)
.github/workflows/relative-ci.yaml
2 participants
Summary
This applies a bunch of security fixes for GH Actions, generated with zizmor:
By running this command:
zizmor . --gh-token $(gh auth token) --fix=allUpdating actions was done with:
npx actions-upRationale
Changes
Impact
Testing
Screenshots/Video
Checklist
Additional Notes
Summary by CodeRabbit