Pin all workflow actions to commit SHAs

[potiuk]

Summary

Pin every third-party action reference in the repo's real workflow files to
an immutable commit SHA, with the human-readable version in a trailing
comment. This follows the GitHub Actions security-hardening guidance: once
a workflow is pinned by SHA, a compromised upstream tag cannot silently
change what our workflows run, and Dependabot treats the trailing # v…
comment as part of the reference so it will bump both the SHA and the
comment when a new release lands.

What changed

Action	Before	After	Where
actions/checkout	@v6.0.2	@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2	check_approved_limit, pelican-action-test (×2), update_actions, linting, remove_expired, update_dummy, codeql-analysis, verify_dependabot_action, pytest, stash-action-test (×3)
actions/setup-python	@v6	@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0	linting
github/codeql-action/{init,autobuild,analyze}	@v4	@c10b8064de6f491fea524254123dbe5e09572f13 # v4.35.1	codeql-analysis

10 workflow files touched, 17 line swaps — no workflow logic changed.

Scope / what is intentionally NOT touched

• .github/workflows/dummy.yml is generated from /actions.yml by
  gateway/gateway.py and regenerated via .github/workflows/update_dummy.yml.
  It has its own pinning convention and any manual edits there would be
  clobbered on the next regeneration.
• gateway/test_out_dummy.yml and the other gateway/*.yml fixtures
  are test data for the gateway generator, not real workflows.
• README example workflow snippets (e.g. pelican/README.md) still
  use floating tags because they are teaching material for end users, not
  production workflows.
• Composite action definitions (stash/{save,restore}/action.yml,
  allowlist-check/action.yml, pelican/action.yml) contain no uses:
  references to third-party actions — they are pure shell: bash run
  steps.

Dependabot coverage

No dependabot.yml change is required. The existing
package-ecosystem: "github-actions" entry already lists / in its
directories list, which covers every workflow file under
.github/workflows/. Dependabot will start proposing version bumps for
the newly-pinned references on its next scheduled run (currently a daily
cron, 15 13 * * *), and it will update both the SHA and the # v…
version comment in place.

Test plan

• Grep confirms no unpinned third-party action references remain in
  any real workflow file — only the two docker://…@sha256:… image
  digests in the dummy.yml fixture, which are already pinned the
  Docker way.
• SHAs resolved via gh api repos/<owner>/<repo>/git/refs/tags/<tag>
  and cross-checked against gh api repos/<owner>/<repo>/tags to
  confirm the tag → SHA mapping and pick the right human-readable
  version for the trailing comment.
• One dependabot cycle after merge to confirm it successfully
  proposes a bump against one of the newly-pinned references (the
  test is "did the next bump arrive with both SHA and comment
  updated" — nothing action-required here, just observation).

🤖 Generated with Claude Code

[raboof]

I'm not sure I agree this is "almost 0 overhead", as it'll create PRs for every patch version bump of these GHA actions, which need to be approved and merged, but generally I'm OK with the change. I do expect your help in reviewing and merging those PRs :)

[ppkarwasz]

While I agree in spirit, I think pinning the CodeQL action is counter-productive: the purpose of the action is to discover bugs or bad practices in code and new rules are added in new releases.

It is probably better to keep this “pinned” to v4. Besides, unlike actions, CodeQL tags are protected: https://github.com/github/codeql-action/rules

[raboof]

While I agree in spirit, I think pinning the CodeQL action is counter-productive: the purpose of the action is to discover bugs or bad practices in code and new rules are added in new releases.

Sure - we'd keep updating it based on dependabot PRs, so we'd get the new rules with those new releases, right?

[ppkarwasz]

I am certain we will update it, but with the amount of additional review work we received, we probably have to choose our battles.

Personally I find using v4 for CodeQL acceptable and in Apache Commons I would recommend this practice, since 40+ PRs every couple of weeks generate a lot of noise.

[raboof]

I am certain we will update it, but with the amount of additional review work we received, we probably have to choose our battles.

Personally I find using v4 for CodeQL acceptable and in Apache Commons I would recommend this practice, since 40+ PRs every couple of weeks generate a lot of noise.

I agree.

[potiuk]

While I agree in spirit, I think pinning the CodeQL action is counter-productive: the purpose of the action is to discover bugs or bad practices in code and new rules are added in new releases.

It is probably better to keep this “pinned” to v4. Besides, unlike actions, CodeQL tags are protected: https://github.com/github/codeql-action/rules

I guess it's the same case as Trivy - it was also a security scanner that has been hacked. And of course we can assume that GH has much more protection on their actions (especially CodeQL), but I think we would be a bit safer if we had hash and some cooldown.

Hacking CodeQL action woudl be extremely lucrative target in general, so I think just for that sake of that very low-probability issue, it's worth to keep (some) cooldown. Also see the cooldown discussion in #683 - I think it is a bit more nuanced discussion.

But yes - security is never 0/1, it's a matter of what kind of scenarios we want to protect against and risk willing to accept.