Update to current setup-go version#13516
Conversation
Update the setup-go version in our private action yml to 1) be pinned by hash (with comment to version string) 2) remove cache disable that was fixed 3 years ago Signed-off-by: Phil Estes <[email protected]>
estesp
added
cherry-pick/1.7.x
estesp
added
cherry-pick/2.2.x
There was a problem hiding this comment.
Pull request overview
Updates the repository’s reusable composite action for installing Go to use the current actions/setup-go release pinned by commit SHA, aligning with the repo’s workflow hardening approach and avoiding failures from deprecated Node runtimes in GitHub-hosted actions.
Changes:
- Pin
actions/setup-goto thev6.4.0commit SHA (with an inline version comment). - Remove the explicit
cache: falseoverride so the action uses the default caching behavior again.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| uses: actions/setup-go@4a3601121dd01d1626a1e23e37211e3254c1c06c # v6.4.0 | ||
| with: | ||
| go-version: ${{ inputs.go-version }} | ||
| cache: false # see actions/setup-go#368 |
There was a problem hiding this comment.
interestingly, I think zizmor recommends disabling the cache for cache poisoning attacks; https://github.com/zizmorcore/zizmor/blob/444728cbaaed0758e9f0885e96f608f1f3ed9441/crates/zizmor/src/audit/cache_poisoning.rs#L65
(on my phone, so didn't have their docs at hand)
There was a problem hiding this comment.
Yeah, I can, but when I read through all the various content on the cache poisoning, all the guidance was concerned with release artifacts, which this specific setup-go is never used in any of our release workflows. However, if we want to be careful, or if there is something I'm not quite getting from the various blog posts on the issue, I'm happy to make the change back.
There was a problem hiding this comment.
Yeah, in all honesty, I'm not sure how much of an attack vector this specific cache is in our case (unless an untrusted part would end up in the same bit as a trusted part; indeed "release" could be relevant there?).
That said, if it doesn't gain much performance (it may not be, as most things are rather ephemeral), perhaps it won't hurt to do.
FWIW; I opened a (currently draft) PR to add a zizmor workflow, which validates actions against many pitfalls;
It doesn't fail (because it only marks changes as failure), but does produce / upload a report for code scanning; https://github.com/containerd/containerd/actions/runs/26944400275/job/79493627210?pr=13531
github-project-automation
Bot
moved this from Needs Triage
to Review In Progress
in Pull Request Review
github-project-automation
Bot
moved this from Review In Progress
to Done
in Pull Request Review
|
/cherry-pick release/2.3 |
|
@dmcgowan: new pull request created: #13686 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Update the setup-go version in our private action yml to:
Apparently dependabot doesn't reach into this directory, so we were close to the cutoff date for Node 20 based actions to start to fail intermittently (in a couple weeks)