fix: fix zizmor security findings in CI workflow files

[siddu-os]

Summary

Ran zizmor v1.25.2 locally against .github/workflows/ and fixed all findings.

Changes

artipacked — Low severity

Added persist-credentials: false to all actions/checkout steps across 18 workflow
files. This prevents the GitHub token from being persisted in the local git config after
checkout, reducing the risk of credential exposure via artifacts.

excessive-permissions — Medium severity

Added explicit permissions: contents: read to all jobs that were using broad default
permissions. Exception: vendor_release.yml uses permissions: contents: write since it
uploads release assets via gh release upload.

archived-uses — Medium severity

Replaced the abandoned actions-rs/toolchain and actions-rs/cargo actions in
aa_sev_kbc.yml with actions-rust-lang/setup-rust-toolchain (already used consistently
across all other workflows in this repo) and an inline run: step respectively.
The actions-rs organisation is archived and no longer receives security updates.

template-injection — Medium severity

In publish-artifacts.yml, replaced ${{ env.RUST_TARGET }} and ${{ env.IMAGE_NAME }}
template expressions inside run: blocks with their shell variable equivalents
$RUST_TARGET / $IMAGE_NAME. Both variables are already defined at the job-level env:
block and are automatically available as shell variables — no step-level redeclaration needed.

cache-poisoning — High severity

In coco-extension-image.yml (new upstream file), added cache: false to the
actions-rust-lang/setup-rust-toolchain step. This workflow triggers on pull_request
and publishes runtime artifacts, making it vulnerable to cache poisoning without this flag.

Verification

zizmor .github/workflows/
# No findings to report. Good job! (88 suppressed)

[mkulke]

what is the rationale behind re-setting the env with the same value? is this a readabiity measure? if yes then it probably makes sense to remove the job-level envs?

        RUST_TARGET: ${{ env.RUST_TARGET }}
        IMAGE_NAME: ${{ env.IMAGE_NAME }}

[fitzthum]

LGTM

[siddu-os]

what is the rationale behind re-setting the env with the same value? is this a readabiity measure? if yes then it probably makes sense to remove the job-level envs?

        RUST_TARGET: ${{ env.RUST_TARGET }}
        IMAGE_NAME: ${{ env.IMAGE_NAME }}

Thanks for the review, You're right - RUST_TARGET and IMAGE_NAME are already defined at the job-level env: block and are automatically available as shell variables in all run: steps. The step-level re-declarations were redundant. Fixed - removed all the unnecessary env: re-assignments. The template-injection fix is achieved simply by using $ RUST_TARGET / $ IMAGE_NAME (shell variables) instead of $ {{ env.RUST_TARGET }} / $ {{ env.IMAGE_NAME }} (template expressions) directly in the run: blocks.