gh aw compile (v0.88.7) emits a Set runtime paths step that writes RUNNER_TOOL_CACHE to $GITHUB_ENV. zizmor flags it as github-env at High severity:
error[github-env]: dangerous use of environment file
--> ./.github/workflows/<workflow>.lock.yml:482:9
|
480 | env:
481 | GH_AW_RUNNER_TOOL_CACHE: ${{ runner.tool_cache }}
482 | / run: |
483 | | if [ -z "${RUNNER_TOOL_CACHE:-}" ]; then
484 | | echo "RUNNER_TOOL_CACHE=${GH_AW_RUNNER_TOOL_CACHE}" >> "$GITHUB_ENV"
| |_______________^ write to GITHUB_ENV may allow code execution
|
= note: audit confidence → Low
The value comes from ${{ runner.tool_cache }}, which the runner sets itself, so there is no caller-controlled input, and zizmor rates its own confidence as Low.
The compiler already suppresses this same rule inline further down the same generated file:
run: | # zizmor: ignore[github-env] - GITHUB_SERVER_URL is set by GitHub Actions, not user input.
Could it emit the same comment on the Set runtime paths step, with an equivalent rationale?
Why it matters. Repositories whose CI gates on fail-severity: high cannot merge a generated workflow at all while this fires. A repo-local .github/zizmor.yml is not a usable workaround either, because the common shared-workflow setup treats a repo-local config as replacing the default policy rather than extending it, so suppressing this one finding silently drops every other org-level suppression and surfaces unrelated findings in files the change never touched.
Reproduce
gh aw compile <workflow> --zizmor
Happy to open a PR if a maintainer confirms the inline-ignore approach is the one you'd want.
gh aw compile(v0.88.7) emits aSet runtime pathsstep that writesRUNNER_TOOL_CACHEto$GITHUB_ENV. zizmor flags it asgithub-envat High severity:The value comes from
${{ runner.tool_cache }}, which the runner sets itself, so there is no caller-controlled input, and zizmor rates its own confidence as Low.The compiler already suppresses this same rule inline further down the same generated file:
Could it emit the same comment on the
Set runtime pathsstep, with an equivalent rationale?Why it matters. Repositories whose CI gates on
fail-severity: highcannot merge a generated workflow at all while this fires. A repo-local.github/zizmor.ymlis not a usable workaround either, because the common shared-workflow setup treats a repo-local config as replacing the default policy rather than extending it, so suppressing this one finding silently drops every other org-level suppression and surfaces unrelated findings in files the change never touched.Reproduce
Happy to open a PR if a maintainer confirms the inline-ignore approach is the one you'd want.