fix: pin 10 unpinned action(s)

[dagecko]

Security: Harden GitHub Actions workflows

Hey, we found some CI/CD security issues in this repo's workflows using Runner Guard, our open-source CI/CD security scanner at Vigilant. These are the same vulnerability classes being actively exploited right now in the tj-actions, Trivy, LiteLLM supply chain attack chain. We scanned the top 50K repos on GitHub and over 20,000 have this same problem. We're trying to get fixes out to as many maintainers as possible before more repos get hit.

This PR fixes what we could automatically, and flags anything else that needs a manual look. There's a real person behind this PR, we're actively checking back on comments so if you have any questions just drop them here and we'll respond.

Fixes applied (in this PR)

Rule	Severity	File	Description
RGS-007	high	.github/workflows/build.yml	Pinned 1 third-party action(s) to commit SHA
RGS-007	high	.github/workflows/documentation-links.yml	Pinned 1 third-party action(s) to commit SHA
RGS-007	high	.github/workflows/lint.yml	Pinned 1 third-party action(s) to commit SHA
RGS-007	high	.github/workflows/require-pr-label.yml	Pinned 4 third-party action(s) to commit SHA
RGS-007	high	.github/workflows/reusable-cifuzz.yml	Pinned 2 third-party action(s) to commit SHA
RGS-007	high	.github/workflows/reusable-wasi.yml	Pinned 1 third-party action(s) to commit SHA

Advisory: additional findings (manual review recommended)

| Rule | Severity | File | Description |
| RGS-006 | high | .github/workflows/jit.yml | Curl-Pipe-Bash Remote Code Execution |
| RGS-006 | high | .github/workflows/jit.yml | Curl-Pipe-Bash Remote Code Execution |
| RGS-006 | high | .github/workflows/reusable-ubuntu.yml | Curl-Pipe-Bash Remote Code Execution |
| RGS-006 | high | .github/workflows/tail-call.yml | Curl-Pipe-Bash Remote Code Execution |
| RGS-005 | medium | .github/workflows/documentation-links.yml | Excessive Permissions on Untrusted Trigger |

Why this matters

GitHub Actions workflows that use untrusted input in run: blocks, expose
secrets inline, or use unpinned third-party actions are vulnerable to
code injection, credential theft, and supply chain attacks. These are the same
vulnerability classes exploited in the tj-actions/changed-files incident
and subsequent supply chain attacks, which compromised CI secrets across
thousands of repositories.

How to verify

Review the diff — each change is mechanical and preserves workflow behavior:

• SHA pinning (RGS-007): Pins third-party actions to immutable commit SHAs
  (original version tag preserved as comment)

Run brew install Vigilant-LLC/tap/runner-guard && runner-guard scan . or install from the
repo to verify.

---

Found by Runner Guard | Built by Vigilant Cyber Security | Learn more

If this PR is not welcome, just close it -- we won't send another.

[python-cla-bot]

The following commit authors need to sign the Contributor License Agreement:

• cnyhuis@vigilantnow.com

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[eendebakpt]

Please follow the python developers guide when making PRs: https://devguide.python.org/. When following the guide, creating issues and PRs is fine.

[brianschubert]

I think we can close this in favor of #146489. This PR appears to be from an automated account that opened 150+ such PRs today: https://github.com/search?q=is%3Apr+author%3Adagecko&type=pullrequests, so they're unlikely to be responsive

[sethmlarson]

Hey, thank you for your interest in Python security.

It looks like you're potentially doing this in an automated way to many repositories. Unless it truly is fixing a vulnerability that is exploitable (which in this case and likely many others: these actions are not exploitable in a meaningful way) I recommend taking a more human-centric approach to each project and contribution. Even little things can go a long way, like:

• Not including a large blurb about why you're opening thousands of PRs or a table showing it's clearly automated behavior on every PR.
• Not opening GHSA tickets unless there is an exploitable vulnerability. If that's the case you wouldn't want a public PR anyway.
• Reading the project contributing guide before submitting a PR.

I am closing this PR in favor of a separate PR that resolves the issue more completely by removing our policy to ignore pinning in our Zizmor configuration.