Experimenting with the new zizmor tool. There's still a number of false-positives so probably not yet worth integrating into our CI run, but have audited the current feedback.
Only persist git credentials where we need to use them
Don't leave these around when we don't need to.
Explicitly set to true where we need them, with a comment highlighting why we're keeping them.
Fix a few places we weren't using the centrally managed checkout version.
Tweak the conditionals for submodules so the with: is always there now.
Use of fundamentally insecure workflow trigger - pull_request_target
These appear ok because we're just using this to comment on community PRs. These don't run builds
error[dangerous-triggers]: use of fundamentally insecure workflow trigger
--> .github/workflows/community-moderation.yml:38:1
|
38 | / on:
39 | | pull_request_target:
... |
42 | | types:
43 | | - opened
| |_____________^ pull_request_target is almost always used insecurely
|
error[dangerous-triggers]: use of fundamentally insecure workflow trigger
--> .github/workflows/pull-request.yml:44:1
|
44 | / on:
45 | | pull_request_target: {}
| |__________________________^ pull_request_target is almost always used insecurely
|
Code injection via template expansion
.github/workflows/master.yml
env.COVERAGE_OUTPUT_DIR may expand into attacker-controllable code
This is not inputtable by a third party user.
.github/workflows/prerequisites.yml
inputs.default_branch may expand into attacker-controllable code
This is a workflow call (reusable workflow) and the input is always set as github.event.repository.default_branch.
.github/workflows/upgrade-provider.yml
github.event.inputs.version may expand into attacker-controllable code
steps.upstream_version.outputs.latest_version may expand into attacker-controllable code
github.repository may expand into attacker-controllable code
steps.target_version.outputs.version may expand into attacker-controllable code
Experimenting with the new zizmor tool. There's still a number of false-positives so probably not yet worth integrating into our CI run, but have audited the current feedback.
Related to:
Only persist git credentials where we need to use them
with:
is always there now.Use of fundamentally insecure workflow trigger -
pull_request_target
These appear ok because we're just using this to comment on community PRs. These don't run builds
Code injection via template expansion
This is not inputtable by a third party user.
This is a workflow call (reusable workflow) and the input is always set as
github.event.repository.default_branch
.This can only be triggered by internal users.