chore(ci): bump actions/setup-go from 5 to 6#63
Conversation
Bumps [actions/setup-go](https://github.com/actions/setup-go) from 5 to 6. - [Release notes](https://github.com/actions/setup-go/releases) - [Commits](actions/setup-go@v5...v6) --- updated-dependencies: - dependency-name: actions/setup-go dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
dependabot[bot] has reached the 50-review limit for trial accounts. To continue receiving code reviews, upgrade your plan.
📝 WalkthroughWalkthroughThe CI workflow is updated to use version 6 of the ChangesCI Dependency Upgrade
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![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
🧹 Nitpick comments (1)
.github/workflows/ci.yml (1)
59-60: ⚡ Quick winLower risk: add explicit trust gating (or document why cache writes can’t happen) for
setup-gocaching
actions/setup-go@v6is configured withcache-dependency-path: go.sumin.github/workflows/ci.ymlfor both steps (around lines 56-60 and 150-153) but there’s no PR trust-boundary guard. Forkpull_requestruns get a read-onlyGITHUB_TOKEN, so cache poisoning via cache writes is generally blocked; however this workflow grants onlypermissions: contents: readand noactionspermission, so cache restore/save behavior is constrained. Add explicit gating (e.g., disable cache onpull_request) or adjust permissions to make the intended behavior unambiguous.🤖 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/ci.yml around lines 59 - 60, The workflow currently uses actions/setup-go@v6 with cache-dependency-path: go.sum but lacks a trust gate for pull_request; update .github/workflows/ci.yml to either disable cache writes on pull_request (e.g., gate the steps using an if condition for github.event_name != 'pull_request') or explicitly set/clarify permissions (e.g., add permissions: actions: write only for trusted branches) so cache restore/save behavior is unambiguous; target the setup-go step(s) that reference cache-dependency-path and the workflow-level permissions: contents: read setting when applying the change.
🤖 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/ci.yml:
- Line 57: Replace the mutable reference uses: actions/setup-go@v6 with a pinned
immutable commit SHA in both the build and contract-tests jobs (locate the
occurrences of "uses: actions/setup-go@v6" and update them to "uses:
actions/setup-go@<COMMIT_SHA>"); ensure both job entries are updated
consistently, and verify the chosen commit SHA corresponds to the desired
actions/setup-go release tag before committing.
---
Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 59-60: The workflow currently uses actions/setup-go@v6 with
cache-dependency-path: go.sum but lacks a trust gate for pull_request; update
.github/workflows/ci.yml to either disable cache writes on pull_request (e.g.,
gate the steps using an if condition for github.event_name != 'pull_request') or
explicitly set/clarify permissions (e.g., add permissions: actions: write only
for trusted branches) so cache restore/save behavior is unambiguous; target the
setup-go step(s) that reference cache-dependency-path and the workflow-level
permissions: contents: read setting when applying the change.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 0b2608d9-4e9b-46bd-8a64-bd74998d8029
📒 Files selected for processing (1)
.github/workflows/ci.yml
|
|
||
| - name: Setup Go | ||
| uses: actions/setup-go@v5 | ||
| uses: actions/setup-go@v6 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify all action refs and detect non-SHA pins in workflows.
# Expected: no `uses:` entries pinned only by tag/version.
rg -nP '^\s*uses:\s*[^@]+@([vV]?\d+(\.\d+){0,2}|main|master)$' .github/workflows || true
# Show all setup-go uses with context.
rg -n -C2 'actions/setup-go@' .github/workflowsRepository: AIX-Format/PiWorker-OS
Length of output: 1785
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the exact setup-go blocks for both occurrences.
nl -ba .github/workflows/ci.yml | sed -n '45,75p'
echo "----"
nl -ba .github/workflows/ci.yml | sed -n '135,165p'Repository: AIX-Format/PiWorker-OS
Length of output: 109
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "---- setup-go @ first occurrence (approx 45-75) ----"
cat -n .github/workflows/ci.yml | sed -n '45,75p'
echo "---- setup-go @ second occurrence (approx 135-165) ----"
cat -n .github/workflows/ci.yml | sed -n '135,165p'Repository: AIX-Format/PiWorker-OS
Length of output: 2075
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show workflow triggers and relevant job context around the setup-go steps.
cat -n .github/workflows/ci.yml | sed -n '1,120p'
echo "----"
cat -n .github/workflows/ci.yml | sed -n '120,220p'Repository: AIX-Format/PiWorker-OS
Length of output: 5432
🌐 Web query:
actions/setup-go cache-dependency-path cache poisoning pull_request from forks write to cache
💡 Result:
Summary: In GitHub Actions, cache poisoning becomes practical when untrusted code (e.g., from a forked PR) can write to the same cache entries that a more-privileged workflow later restores. Two key pieces matter for your query (setup-go + pull_request from forks + write to cache). 1) What actions/setup-go does with cache-dependency-path - actions/setup-go has built-in caching for “Go modules and build outputs”. Caching is enabled by default via its cache input; you can disable it with cache: false.[1] - The cache key includes hashes of dependency files. By default, it looks for go.mod and uses its hash as part of the cache key; to use go.sum (or other files), set cache-dependency-path (supports glob patterns).[1] 2) Whether forked pull_request workflows can write to caches used elsewhere - GitHub Docs warn not to store sensitive information in caches because “Anyone with read access can create a pull request on a repository and access the contents of a cache” and “forks of a repository can create pull requests on the base branch and access caches on the base branch.”[2] - GitHub Docs also describe cache scope behavior specifically for PRs: when a workflow run is triggered for a pull request, the cache is created for the merge ref (refs/pull/.../merge), so it “can only be restored by re-runs of the pull request” and “cannot be restored by the base branch or other pull requests targeting that base branch.”[2] - Implication: with the normal pull_request event (and the typical security model), PR-created caches should not be a simple “write once, poison later in main” channel, because of that limited scope.[2] 3) The main way “write to cache from forks” becomes dangerous: pull_request_target - The practical “poison the cache for a later trusted run” pattern appears when workflows are triggered with pull_request_target, because it runs in the context of the base repository (so the attacker’s code can execute with base-repo permissions, including the ability to interact with cache). This is described in the TanStack cache poisoning write-up: the attack used pull_request_target instead of pull_request, noting that it runs in the context of the base repository and “can access secrets and can write to the Actions cache — even from a forked PR.”[3] 4) Mitigations that follow from the above (what to do for setup-go caching) - Security conservative mitigation: disable setup-go caching in workflows that may execute untrusted code (especially anything resembling pull_request_target). This is explicitly recommended/implemented in a GitHub change: “disable Go module cache in agentic setup actions to prevent cache poisoning”, changing actions/setup-go usage to set cache: false (because caching enabled by default exposes a cache poisoning vector).[4] - If you need caching, isolate by context: GitHub’s cache poisoning guidance emphasizes preventing untrusted PR workflows from writing to caches used by privileged/release pipelines; one key rule is to “separate caches” so PR workflows cannot overwrite what release workflows will restore.[5] - Use restore-only patterns when appropriate: actions/cache provides actions/cache/restore that restores but does not save (so it’s “granular ability to restore a cache without having to save it”).[6] (Separating restore and save reduces write capability from untrusted contexts.) Concrete answer to your query terms - cache-dependency-path: controls what dependency file(s) are hashed for the setup-go cache key (default uses go.mod hash; you can point it at go.sum via cache-dependency-path).[1] - pull_request from forks write to cache: under normal pull_request scope rules, PR-created caches are tied to refs/pull/.../merge and aren’t restorable by base branch or other PRs, so “write to cache then have main restore it” is not straightforward.[2] - However, with pull_request_target (base repo context), forked PR code can gain access that enables cache poisoning/write scenarios.[3] Recommended workflow guidance (short) - For workflows that may run untrusted PR code (particularly anything using pull_request_target), set cache: false on actions/setup-go.[4][1] - For trusted workflows (main/release), you can keep caching enabled, but ensure untrusted workflows never have permission or execution context that allows them to save/poison the same cache keys that trusted workflows restore.[5][3]
Citations:
- 1: https://github.com/actions/setup-go/
- 2: https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching
- 3: https://dev.to/pvgomes/what-now-explaining-the-tanstack-supply-chain-attack-1cfh
- 4: fix: disable Go module cache in agentic setup actions to prevent cache poisoning github/gh-aw#19865
- 5: https://codeql.github.com/codeql-query-help/actions/actions-cache-poisoning-direct-cache/
- 6: https://github.com/actions/cache/blob/667d8fdfa213683cee9fcaad43be0f25322bef02/restore/README.md
Pin actions/setup-go to an immutable commit SHA (mutable @v6 in two steps).
uses: actions/setup-go@v6 is a mutable reference and weakens CI supply-chain integrity; pin to a full commit SHA in both the build and contract-tests jobs.
Suggested hardening diff
- uses: actions/setup-go@v6
+ uses: actions/setup-go@<full-length-commit-sha-for-v6>
...
- uses: actions/setup-go@v6
+ uses: actions/setup-go@<full-length-commit-sha-for-v6>- Workflow runs on
pull_request(notpull_request_target), so cross-branch cache poisoning is less straightforward; if your policy treats PR caches as untrusted, consider settingcache: falseforpull_request.
🧰 Tools
🪛 zizmor (1.25.2)
[error] 57-57: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 57-57: runtime artifacts potentially vulnerable to a cache poisoning attack (cache-poisoning): enables caching by default
(cache-poisoning)
🤖 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/ci.yml at line 57, Replace the mutable reference uses:
actions/setup-go@v6 with a pinned immutable commit SHA in both the build and
contract-tests jobs (locate the occurrences of "uses: actions/setup-go@v6" and
update them to "uses: actions/setup-go@<COMMIT_SHA>"); ensure both job entries
are updated consistently, and verify the chosen commit SHA corresponds to the
desired actions/setup-go release tag before committing.
Bumps actions/setup-go from 5 to 6.
Release notes
Sourced from actions/setup-go's releases.
... (truncated)
Commits
4a36011docs: fix Microsoft build of Go link (#734)8f19afcfeat: add go-download-base-url input for custom Go distributions (#721)27fdb26Bump minimatch from 3.1.2 to 3.1.5 (#727)def8c39Rearrange README.md, add advanced-usage.md (#724)4b73464Fix golang download url to go.dev (#469)a5f9b05Update default Go module caching to use go.mod (#705)7a3fe6cBump qs from 6.14.0 to 6.14.1 (#703)b9adafdBump actions/checkout from 5 to 6 (#686)d73f6bcREADME.md: correct to actions/checkout@v6 (#683)ae252eeBump@actions/cacheto v5 (#695)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)Summary by CodeRabbit