Repository navigation
Harden gh actions workflows - #3759
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (12)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (7)
📝 WalkthroughWalkthroughWorkflows and Dependabot config updated: Dependabot gains a 7-day cooldown; many GitHub Actions workflows add explicit Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/build-debian-multiarch.yml:
- Around line 38-40: The workflow's permissions block only grants contents: read
but the uraimo/run-on-arch-action steps use githubToken to cache GHCR images;
update the permissions block (the top-level permissions: mapping) to include
packages: write and packages: read so the action can push and pull container
cache layers when the install step runs; locate the permissions block in the
workflow and add the two packages entries alongside contents: read.
🪄 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: CHILL
Plan: Pro
Run ID: 0d06e897-f44b-485b-9c89-a5abe40cd455
📒 Files selected for processing (12)
.github/dependabot.yml.github/workflows/build-debian-multiarch.yml.github/workflows/build-emsdk.yml.github/workflows/build-macos.yml.github/workflows/build-manylinux.yml.github/workflows/build-sdl3.yml.github/workflows/build-ubuntu-sdist.yml.github/workflows/build-windows.yml.github/workflows/dev-check.yml.github/workflows/release-gh-draft.yml.github/workflows/release-pypi.yml.github/workflows/run-ubuntu-checks.yml
57012c3 to
4329d03
Compare
Starbuck5
left a comment
There was a problem hiding this comment.
Did you mean to add permissions to build-manylinux as well?
Otherwise happy to go with this, thanks for checking it out Ankith.
|
build-manylinux already has permissions defined but at the job level not workflow level. This is fine for now because the workflow has only one job defined but this can be changes in the future. |
After learning about the recent litellm security incident (TL;DR: supply chain attack via github actions, the PyPI token of a popular library was leaked to attackers who released bad releases that then compromised user creds and so on) I was prompted into further scrutinizing our own actions for security.
The good news is that we are already pretty secure in terms of PyPI publishing. We don't use a static PyPI token and instead use the recommended Trusted PyPI Publisher approach for managing our releases. So an attack like the above mentioned case wouldn't be possible with us.
But still, to be cautious (using zizmor for github actions static analysis) this PR identifies and fixes a couple of security gotchas, mainly under three categories: