chore(actions): address zizmor findings#836
Conversation
This PR is an auto-generated attempt to address zizmor findings. It may not catch everything, and should be reviewed by repository owners. If it is unhelpful, feel free to close the PR and address separately. This PR was generated by running `zizmor --fix=all --gh-token=$(gh auth token) ./.github/workflows`. See go/github-zizmor-help for instructions to install and run. If this PR is helpful, feel free to approve and merge, or edit/modify as needed to get it to the right state. Repository owners must ultimately ensure compliance by 2026-07-13. The purpose of this PR is to provide some assistance with achieving that as a first pass. This will become a blocking check for new changes to github workflows on 2026-07-13 within the `googleapis` org. There may be some ignored findings (with the comment `# zizmor: ignore[...]`), which you may fix if feasible.
product-auto-label
Bot
added
the
api: actions
|
(Closed the PR by accident, reopened) |
| style: | ||
| name: PHP Style Check | ||
| uses: GoogleCloudPlatform/php-tools/.github/workflows/code-standards.yml@main | ||
| uses: GoogleCloudPlatform/php-tools/.github/workflows/code-standards.yml@main # zizmor: ignore[unpinned-uses] |
There was a problem hiding this comment.
why don't we just pin these? I don't particularly like annotations for a tool I don't use. Alternatively we can just ignore them without the annotation, as this tool is not being run regularly on CI (or is it?)
There was a problem hiding this comment.
why don't we just pin these?
My thinking was that 1P deps (like googleapis or GCP or anything maintained by google and updated frequently) can be kept on latest (if repo owners prefer), for convenience. But if you prefer, can pin them. My assumption was that when depending on a shared workflow/image for builds, you are prob ok with always pulling the latest iff its a "trusted" 1P source, as they will prob be updated somewhat frequently and safer to be on latest than an old one.
But ofc these are all assumptions :) so lmk what you prefer.
as this tool is not being run regularly on CI (or is it?)
I think it will run on every PR once fully enforced
There was a problem hiding this comment.
Since we are enabling config:best-practices for Renovate in this PR, Renovate will automatically keep the SHAs up to date for us anyway. I agree with Brent that we should pin those 1P workflows and images to SHAs so we can get rid of the inline zizmor annotations entirely.
Otherwise looks great. Thanks for addressing the zizmor security findings and hardening our GitHub Actions.
A few highlights I appreciate here:
- Enforcing the least-privilege principle by explicitly defining
permissions: contents: readwhere they were previously absent. - Securing the checkout steps by explicitly disabling
persist-credentials. - Pinning the action dependencies to immutable commit SHAs, and pairing that with the
config:best-practicesRenovate update to ensure the SHAs stay up to date. - Properly managing
zizmorignores for the trustedGoogleCloudPlatform/php-toolsreusable workflows.
4 participants
This PR is an auto-generated attempt to address zizmor findings. It may not catch everything, and should be reviewed by repository owners.
These changes were generated by running
zizmor --fix=all --gh-token=$(gh auth token) ./.github/workflows, and then applying some fixes for any remaining issues reported by zizmor. See go/github-zizmor-help for instructions to install and run.Additionally, it updates renovate configuration (if present) to extend best-practices, which includes pinning action digests and image digests, among other things.
If this PR is unhelpful, feel free to close the PR and address separately. If it is helpful, feel free to approve and merge, or edit/modify as needed to get it to the right state. Repository owners must ultimately ensure compliance by 2026-07-13. The purpose of this PR is to provide some assistance with achieving that as a first pass. This will become a blocking check for new changes to github workflows on 2026-07-13 within the
googleapisorg.There may be some ignored findings (with the comment
# zizmor: ignore[...]), which you may fix if feasible.