ci: reuse cargo-component installer in live canary - #5101
theredspoon wants to merge 6 commits into
Conversation
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
📝 WalkthroughSummary by CodeRabbit
WalkthroughLive-canary jobs replace inline ChangesCI workflow updates
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
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 |
github-actions
Bot
added
risk: medium
![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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/live-canary.yml (1)
477-478: 🔒 Security & Privacy | 🔴 Critical | ⚡ Quick winDo not run a repo-local action from the checked-out ref in these privileged lanes.
These steps now execute
./.github/actions/install-cargo-componentfrom whatever ref was checked out. Inpublic-smoke,persona-rotating,private-oauth, andprovider-matrix, that means branch-controlled action code runs before or alongside live secrets;private-oauthalso does it on theironclaw-liveself-hosted runner. Call the pinned upstream action directly here instead of routing through a workspace-local composite.Suggested fix
- name: Install cargo-component - uses: ./.github/actions/install-cargo-component + uses: taiki-e/install-action@62b0f2dec647a8e604c6a0fda0e38530180dce20 # v2 + with: + tool: cargo-component@0.21.1As per path instructions,
.github/workflows/**: "flag privileged workflows that check out or execute PR-controlled code".Also applies to: 793-794, 849-850, 901-902
🤖 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/live-canary.yml around lines 477 - 478, This workflow step is executing the repo-local install-cargo-component composite from the checked-out ref in privileged lanes, which allows PR-controlled code to run near live secrets. Update the affected jobs (public-smoke, persona-rotating, private-oauth, and provider-matrix) to call the pinned upstream cargo-component action directly instead of uses: ./.github/actions/install-cargo-component, keeping the workflow on trusted, version-pinned action code only.Source: Path instructions
🤖 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/live-canary.yml:
- Around line 693-695: The `Install cargo-component` step is still swallowing
failures with `|| true`, which breaks the fail-fast behavior for
`reborn-webui-v2-live-qa`. Remove the fallback so the `cargo install
cargo-component` command in this workflow step fails the job immediately if
installation breaks, keeping the subsequent `Build WASM channels` step from
masking the real issue.
---
Outside diff comments:
In @.github/workflows/live-canary.yml:
- Around line 477-478: This workflow step is executing the repo-local
install-cargo-component composite from the checked-out ref in privileged lanes,
which allows PR-controlled code to run near live secrets. Update the affected
jobs (public-smoke, persona-rotating, private-oauth, and provider-matrix) to
call the pinned upstream cargo-component action directly instead of uses:
./.github/actions/install-cargo-component, keeping the workflow on trusted,
version-pinned action code only.
🪄 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: 68ee2bae-040c-4b70-9fc9-ee4145c3966e
📒 Files selected for processing (1)
.github/workflows/live-canary.yml
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/live-canary.yml (1)
477-478: 🔒 Security & Privacy | 🔴 Critical | ⚡ Quick winDo not run a repo-local action from the checked-out ref in these privileged lanes.
These steps now execute
./.github/actions/install-cargo-componentfrom whatever ref was checked out. Inpublic-smoke,persona-rotating,private-oauth, andprovider-matrix, that means branch-controlled action code runs before or alongside live secrets;private-oauthalso does it on theironclaw-liveself-hosted runner. Call the pinned upstream action directly here instead of routing through a workspace-local composite.Suggested fix
- name: Install cargo-component - uses: ./.github/actions/install-cargo-component + uses: taiki-e/install-action@62b0f2dec647a8e604c6a0fda0e38530180dce20 # v2 + with: + tool: cargo-component@0.21.1As per path instructions,
.github/workflows/**: "flag privileged workflows that check out or execute PR-controlled code".Also applies to: 793-794, 849-850, 901-902
🤖 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/live-canary.yml around lines 477 - 478, This workflow step is executing the repo-local install-cargo-component composite from the checked-out ref in privileged lanes, which allows PR-controlled code to run near live secrets. Update the affected jobs (public-smoke, persona-rotating, private-oauth, and provider-matrix) to call the pinned upstream cargo-component action directly instead of uses: ./.github/actions/install-cargo-component, keeping the workflow on trusted, version-pinned action code only.Source: Path instructions
🤖 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/live-canary.yml:
- Around line 693-695: The `Install cargo-component` step is still swallowing
failures with `|| true`, which breaks the fail-fast behavior for
`reborn-webui-v2-live-qa`. Remove the fallback so the `cargo install
cargo-component` command in this workflow step fails the job immediately if
installation breaks, keeping the subsequent `Build WASM channels` step from
masking the real issue.
---
Outside diff comments:
In @.github/workflows/live-canary.yml:
- Around line 477-478: This workflow step is executing the repo-local
install-cargo-component composite from the checked-out ref in privileged lanes,
which allows PR-controlled code to run near live secrets. Update the affected
jobs (public-smoke, persona-rotating, private-oauth, and provider-matrix) to
call the pinned upstream cargo-component action directly instead of uses:
./.github/actions/install-cargo-component, keeping the workflow on trusted,
version-pinned action code only.
🪄 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: 68ee2bae-040c-4b70-9fc9-ee4145c3966e
📒 Files selected for processing (1)
.github/workflows/live-canary.yml
🛑 Comments failed to post (1)
.github/workflows/live-canary.yml (1)
693-695: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Stop swallowing
cargo-componentinstall failures in this lane.Line 695 still keeps
|| true, soreborn-webui-v2-live-qacan mask a broken install and fail later inBuild WASM channelswith a worse error. That leaves this job out of the new fail-fast contract the shared installer was meant to enforce.Suggested fix
- name: Install cargo-component if: steps.resolve_reborn_webui_v2_cases.outputs.skip_shard != '1' - run: cargo install cargo-component --locked || true + uses: taiki-e/install-action@62b0f2dec647a8e604c6a0fda0e38530180dce20 # v2 + with: + tool: cargo-component@0.21.1📝 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.- name: Install cargo-component if: steps.resolve_reborn_webui_v2_cases.outputs.skip_shard != '1' uses: taiki-e/install-action@62b0f2dec647a8e604c6a0fda0e38530180dce20 # v2 with: tool: cargo-component@0.21.1🤖 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/live-canary.yml around lines 693 - 695, The `Install cargo-component` step is still swallowing failures with `|| true`, which breaks the fail-fast behavior for `reborn-webui-v2-live-qa`. Remove the fallback so the `cargo install cargo-component` command in this workflow step fails the job immediately if installation breaks, keeping the subsequent `Build WASM channels` step from masking the real issue.
github-actions
Bot
added
size: M
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/live-canary.yml:
- Around line 478-480: The workflow jobs are duplicating the cargo-component
install action instead of reusing the shared composite action, which breaks the
single-source-of-truth pinning. Update each affected job in live-canary.yml to
call ./.github/actions/install-cargo-component rather than inlining
taiki-e/install-action and cargo-component@0.21.1, matching the existing usage
in workflow-canary and deterministic-replay so future version bumps only change
one place.
🪄 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: 24cce5e9-e94c-4ed1-8af6-afeff05c4032
📒 Files selected for processing (1)
.github/workflows/live-canary.yml
74ca27b to
359c49b
Compare
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/actionlint.yaml (1)
1-6: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueRunner label matches usage;
config-variables: nulldisables vars-context validation.Label
ironclaw-livecorrectly lines up withruns-on: [self-hosted, ironclaw-live]inprivate-oauth. Settingconfig-variables: nullmeans actionlint stops checking${{ vars.* }}refs (e.g.AUTH_LIVE_GITHUB_OWNER,AUTH_LIVE_NOTION_QUERY) against a known list — fine for suppressing false positives, but note it also silences genuine typo detection onvars.*names going forward.🤖 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/actionlint.yaml around lines 1 - 6, The runner label configuration under self-hosted-runner already matches the workflow usage, but config-variables: null disables actionlint validation for vars.* references. Update the actionlint config to keep the ironclaw-live label mapping while replacing the null vars setting with an explicit allowed variables list if you want typo detection to continue working for AUTH_LIVE_GITHUB_OWNER, AUTH_LIVE_NOTION_QUERY, and similar references.
🤖 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/actionlint.yaml:
- Around line 1-6: The runner label configuration under self-hosted-runner
already matches the workflow usage, but config-variables: null disables
actionlint validation for vars.* references. Update the actionlint config to
keep the ironclaw-live label mapping while replacing the null vars setting with
an explicit allowed variables list if you want typo detection to continue
working for AUTH_LIVE_GITHUB_OWNER, AUTH_LIVE_NOTION_QUERY, and similar
references.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 12800527-3ad7-49be-a7ff-225c6e698a92
📒 Files selected for processing (2)
.github/actionlint.yaml.github/workflows/live-canary.yml
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/live-canary.yml (1)
478-480: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicated inline installer, likely intentional — but drift risk remains.
This matches a prior review comment about 6 jobs duplicating
taiki-e/install-action@62b0f2dec647a8e604c6a0fda0e38530180dce20 # v2(cargo-component@0.21.1) instead of calling./.github/actions/install-cargo-component. Per the PR objective, this is now deliberate: privileged/self-hosted lanes call the pinned upstream installer directly so repo-local composite-action code isn't executed at the privileged boundary (relevant sincereborn-webui-v2-live-qacan check out an attacker-influencedtarget_ref, lines 617-646). That rationale is sound for the security boundary.However, the DRY problem it reintroduces (version bump now touches 7 files) is still real and separable from the trust boundary. Consider pinning the version once via a workflow-level
env:and referencing it in each inline step, keeping the direct-to-upstream call but restoring single-source version control:♻️ Reduce version drift while keeping the direct upstream call
env: + CARGO_COMPONENT_VERSION: cargo-component@0.21.1 ... - name: Install cargo-component uses: taiki-e/install-action@62b0f2dec647a8e604c6a0fda0e38530180dce20 # v2 with: - tool: cargo-component@0.21.1 + tool: ${{ env.CARGO_COMPONENT_VERSION }}As per path instructions for
.github/workflows/**, flag unpinned/duplicated third-party action usage that undercuts single-source-of-truth pinning.Also applies to: 697-699, 798-800, 856-858, 910-912, 980-982
🤖 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/live-canary.yml around lines 478 - 480, The inline `taiki-e/install-action` steps are intentionally kept for the privileged lanes, but the repeated pinned version in `live-canary.yml` creates drift risk when updating `cargo-component@0.21.1`. Keep the direct upstream installer in place for the security boundary, but centralize the version in a workflow-level `env` or similar single source and reference it from each install step so the pinned `install-action` value is updated once. Use the duplicated install blocks around the `cargo-component` setup steps as the target for the refactor.Source: Path instructions
🤖 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/live-canary.yml:
- Around line 478-480: The inline `taiki-e/install-action` steps are
intentionally kept for the privileged lanes, but the repeated pinned version in
`live-canary.yml` creates drift risk when updating `cargo-component@0.21.1`.
Keep the direct upstream installer in place for the security boundary, but
centralize the version in a workflow-level `env` or similar single source and
reference it from each install step so the pinned `install-action` value is
updated once. Use the duplicated install blocks around the `cargo-component`
setup steps as the target for the refactor.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 9bc4b25e-6ecc-4369-b733-b30db4e311d8
📒 Files selected for processing (2)
.github/actionlint.yaml.github/workflows/live-canary.yml
359c49b to
9f03fdb
Compare
IronLoop Review StatusHead: Current reviewers:
Recent activity:
Commands:
|
|
Reviewed and rebased onto current Clean CI hardening: replaces
Ready for a maintainer merge. |
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/live-canary.yml:
- Around line 736-752: The issue is that `setup-sccache-dist` is still
referenced from the PR checkout, so the workflow can execute untrusted composite
action changes with sensitive secrets in scope. Update the `Setup OVH sccache`
steps in `live-canary.yml` to use the canonical harness checkout for
`setup-sccache-dist`, matching the existing pattern used for restored `scripts/`
and `tests/e2e`, and apply the same fix to the repeated occurrence later in the
workflow. Ensure the action reference is resolved from the trusted canonical
source rather than `./.github/actions/setup-sccache-dist` in the PR tree.
🪄 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: 3a813490-f71d-4227-ab1e-3d4b7f815c0d
📒 Files selected for processing (2)
.github/actionlint.yaml.github/workflows/live-canary.yml
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
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/live-canary.yml:
- Around line 736-752: The issue is that `setup-sccache-dist` is still
referenced from the PR checkout, so the workflow can execute untrusted composite
action changes with sensitive secrets in scope. Update the `Setup OVH sccache`
steps in `live-canary.yml` to use the canonical harness checkout for
`setup-sccache-dist`, matching the existing pattern used for restored `scripts/`
and `tests/e2e`, and apply the same fix to the repeated occurrence later in the
workflow. Ensure the action reference is resolved from the trusted canonical
source rather than `./.github/actions/setup-sccache-dist` in the PR tree.
🪄 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: 3a813490-f71d-4227-ab1e-3d4b7f815c0d
📒 Files selected for processing (2)
.github/actionlint.yaml.github/workflows/live-canary.yml
🛑 Comments failed to post (1)
.github/workflows/live-canary.yml (1)
736-752: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash # Inspect the composite action to assess what it executes and whether it touches secrets/untrusted refs. fd -HI 'action.yml|action.yaml' .github/actions/setup-sccache-dist cat .github/actions/setup-sccache-dist/action.yml 2>/dev/null || cat .github/actions/setup-sccache-dist/action.yaml # Confirm whether this step existed prior to this PR (check blame/log for the step). rg -n "Setup OVH sccache" .github/workflows/live-canary.ymlRepository: nearai/ironclaw
Length of output: 7699
🏁 Script executed:
#!/bin/bash set -euo pipefail # Show the relevant workflow region around the checkout and the sccache step. sed -n '660,760p' .github/workflows/live-canary.yml # Check whether the repo-local action is invoked after the attacker-controlled checkout. rg -n "uses: \./\.github/actions/setup-sccache-dist|uses: actions/checkout|target_ref|head_sha|skip_shard" .github/workflows/live-canary.yml # Inspect whether the composite action itself is modified by this PR or simply reused. git diff -- .github/actions/setup-sccache-dist/action.yml .github/workflows/live-canary.ymlRepository: nearai/ironclaw
Length of output: 9832
Pin
setup-sccache-distto the canonical harness. In.github/workflows/live-canary.yml:691-752, the canonical checkout only restoresscripts/andtests/e2e;./.github/actions/setup-sccache-diststill comes from the PR-checked-out tree, so a same-repotarget_refcan change the composite action and run it withNEARAI_API_KEY/ Slack / OAuth secrets in scope. Same pattern repeats at.github/workflows/live-canary.yml:913-922.🤖 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/live-canary.yml around lines 736 - 752, The issue is that `setup-sccache-dist` is still referenced from the PR checkout, so the workflow can execute untrusted composite action changes with sensitive secrets in scope. Update the `Setup OVH sccache` steps in `live-canary.yml` to use the canonical harness checkout for `setup-sccache-dist`, matching the existing pattern used for restored `scripts/` and `tests/e2e`, and apply the same fix to the repeated occurrence later in the workflow. Ensure the action reference is resolved from the trusted canonical source rather than `./.github/actions/setup-sccache-dist` in the PR tree.Source: Path instructions
…eborn-webui-v2-live-qa The Setup OVH sccache step in prepare-reborn-webui-v2-live-qa runs after a checkout pinned to steps.target.outputs.checkout_ref, which can be a validated same-repo PR head SHA. Resolving the secrets-touching ./.github/actions/setup-sccache-dist composite from that ref let a same-repo branch swap in malicious composite-action code that would run with SCCACHE_DIST_AUTH_TOKEN and the OVH Redis SSH key in scope. Add a second checkout pinned to the repository default branch at a dedicated path and resolve the composite action from there instead, matching the canonical-checkout idiom already used to restore the Reborn WebUI v2 live QA harness in the reborn-webui-v2-live-qa job.
9f03fdb to
79158f9
Compare
|
Fixed the
Fixed in New head: |
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
@ilblackdragon, resurfacing this since the original ask is buried in a resolved review thread. You approved this back on 2026-07-04 (#5101 (comment)), but it was posted as a comment rather than a formal GitHub review, so it never actually registered against branch protection and the PR sat unmerged. It then drifted ~610 commits behind upstream/main over the following month. Since then: rebased onto current main, plus a new fix (canonical-checkout pinning for Could use a fresh review/approval when you get a chance — this time via the actual Review → Approve action so it registers and can enter the merge queue. Branch protection currently shows |
…-canary-cargo-component
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
The Remove canonical action checkout step in prepare-reborn-webui-v2-live-qa lacked always(), so a failed Setup OVH sccache step would skip cleanup of .canonical-live-canary-actions. Low-impact on ephemeral ubuntu-latest today, but latent fragility given the workflow also has a persistent self-hosted runner elsewhere with no build-state cleanup between jobs.
…-canary-cargo-component # Conflicts: # .github/workflows/live-canary.yml
github-actions
Bot
added
size: S
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
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/live-canary.yml:
- Around line 812-816: Update the “Remove canonical action checkout” cleanup
step so `.canonical-live-canary-actions` remains available until the referenced
`mozilla-actions/sccache-action` post step and all other job post steps have
completed; move cleanup to a point after those actions finish while preserving
the existing conditional cleanup behavior.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 3ce165b4-cf36-4038-8e1f-b6e5607de479
📒 Files selected for processing (2)
.github/actionlint.yaml.github/workflows/live-canary.yml
This branch has not been deployed
2 participants
Summary
cargo install cargo-component --locked || truesource installs with pinnedtaiki-e/install-actionusage.ironclaw-liveself-hosted runner label and clean up provider env writes so plain actionlint passes.setup-sccache-distfrom a canonical (default-branch) checkout inprepare-reborn-webui-v2-live-qainstead of the PR-controlled checkout, closing a supply-chain gap where a same-repo branch could swap in malicious composite-action code with secrets in scope (79158f92e).Change Type
CI / workflow hardening.
Linked Issue
None.
Test Strategy
User behavior: Not applicable: this is a CI/workflow-only change (
.github/workflows/live-canary.yml,.github/actionlint.yaml); no user-facing behavior is affected.Risk areas:
Tests added or updated:
actionlint, and a manualcheckout ref:audit across every live-canary job (see Review Track below) confirming which jobs resolve action code from a PR-influenceable ref vs. a canonical/default-branch ref.What the tests prove: The workflow YAML is syntactically valid,
actionlintpasses cleanly, and the manual audit confirms no privileged (live-secret / self-hosted) lane resolves action code from a PR-controlled checkout.Commands run:
git diff --check -- .github/workflows/live-canary.yml .github/actionlint.yamlruby -e 'require "yaml"; YAML.load_file(".github/workflows/live-canary.yml"); YAML.load_file(".github/actionlint.yaml"); puts "yaml ok"'actionlint .github/workflows/live-canary.ymlrg -n "Install cargo-component|cargo install cargo-component|install-cargo-component|taiki-e/install-action" .github/workflows/live-canary.ymlSecurity Impact
Positive. Privileged lanes (live-secret / self-hosted) invoke the pinned upstream
taiki-e/install-actiondirectly rather than a repo-local composite, andsetup-sccache-distis now resolved from a canonical checkout rather than the PR-controlled ref, removing a path for a same-repo branch to run malicious composite-action code withSCCACHE_DIST_AUTH_TOKENand the OVH Redis SSH key in scope.Reborn Trust-Boundary Checklist
N/A: this PR only touches CI workflow configuration (
.github/workflows/live-canary.yml,.github/actionlint.yaml). It adds or modifies no Reborn runtime/policy/evidence/trust-bearing types, prompt-construction paths, hashing, status/exit/policy variants,serde(default)fields, queues/buffers, or sandboxed driver code, so these checklist items don't apply. The GitHub Actions trust boundary this PR does affect (privileged live-secret/self-hosted lanes must not execute repo-local composite-action code resolved from a PR-controlled checkout) is covered under Security Impact and Review Track.Database Impact
None.
Blast Radius
Limited to
.github/workflows/live-canary.yml(still the only file this PR touches). The workflow change affects cargo-component installation before WASM extension/channel builds in live-canary lanes, plus the checkout used to resolvesetup-sccache-distinprepare-reborn-webui-v2-live-qa. A subsequentupstream/mainmerge (see Review Track) removed theprovider-matrixjob upstream, which also removed this PR's own cargo-component change to that job; the file is no longer byte-for-byte a superset of the pre-merge diff, but no other job's content from this PR was affected.Rollback Plan
Revert this PR to return live-canary cargo-component installation, actionlint config, and the sccache checkout to the previous workflow behavior.
Review Follow-Through
upstream/main(d8be0c0de, the Waves 0-4 batch) via a merge commit rather than a rebase;.github/workflows/live-canary.ymlwas untouched by that upstream commit.setup-sccache-distsupply-chain finding (PR-controlled checkout resolving a secrets-touching composite action) was fixed via a canonical-checkout step (79158f92e).ilblackdragon's 2026-07-04 APPROVE predates the 341-file merge, and was posted as a plain issue comment rather than a formal GitHub review, so it never registered against branch protection. theredspoon re-requested a formal review from@ilblackdragonon 2026-08-05T03:51:56Z, explaining this distinction and noting the PR had drifted ~610 commits behindupstream/mainby that point. No reply fromilblackdragonsince. The branch has since taken a secondupstream/mainmerge (bc04fe816, 2026-08-05T22:23:50-03:00) plus the crash-safe cleanup follow-up below (f62d9e7d3, 2026-08-05T22:54:56-03:00); branch protection still showsREVIEW_REQUIREDwith no formal approval on record. Current drift vsupstream/mainis 54 commits.Review Track
CI/security review. Current head is
4845ffa84(a thirdupstream/mainmerge, 0 commits behindupstream/main; previous headf62d9e7d3was the follow-up fix making the canonical-checkout cleanup crash-safe). This merge resolved a modify/delete conflict: upstream commit226bd491d(#7418) deleted theprovider-matrixjob entirely (job body, weekly cron trigger,workflow_dispatchdropdown option,canary-report's dependency on it, and its zizmor pre-install steps), while this branch had independently repointed that same job's cargo-component install to the pinnedtaiki-e/install-action. Resolution took upstream's deletion as-is rather than resurrecting the job; the four remaining privileged lanes (public-smoke,persona-rotating,private-oauth,release-public-full) still call the pinned installer directly and the two non-privileged lanes (workflow-canary,deterministic-replay) still use the local composite, so this PR's own substance is otherwise unaffected. PR isMERGEABLE.mergeStateStatusisBLOCKEDpending a fresh approving review: the 2026-07-04 "APPROVE" fromilblackdragonwas posted as a plain issue comment, not a formal GitHub review, so it never registered against branch protection. theredspoon explicitly re-requested review from@ilblackdragonon 2026-08-05T03:51:56Z, explaining the informal-comment-vs-formal-review distinction and noting the ~610-commit drift at that time; no reply yet. Main point to check is that privileged lanes use pinned action code directly and resolve secrets-touching composites from a canonical checkout, while lower-privilege lanes may continue using the repo-local composite.Validation
git diff --check -- .github/workflows/live-canary.yml .github/actionlint.yamlruby -e 'require "yaml"; YAML.load_file(".github/workflows/live-canary.yml"); YAML.load_file(".github/actionlint.yaml"); puts "yaml ok"'actionlint .github/workflows/live-canary.ymlrg -n "Install cargo-component|cargo install cargo-component|install-cargo-component|taiki-e/install-action" .github/workflows/live-canary.ymlFollow-up: canonical-checkout cleanup made crash-safe
Remove canonical action checkoutstep inprepare-reborn-webui-v2-live-qaonly ranif: steps.lookup.outputs.found != '1', so it was skipped whenever the preceding secrets-touchingsetup-sccache-diststep failed.always()to the step's condition (if: always() && steps.lookup.outputs.found != '1') so cleanup of.canonical-live-canary-actionsruns unconditionally, alongside its existing guard.