action-allowlist-review: bump runs-on/action from 2.1.0 to 2.1.1 in /.github/actions/for-dependabot-triggered-reviews

[dependabot]

Bumps runs-on/action from 2.1.0 to 2.1.1.

Release notes

Sourced from runs-on/action's releases.

v2.1.1

What's Changed

• Upgrade go, deps, and sanitize values better by @​crohr in runs-on/action#30
• Propagate actions runtime token by @​crohr in runs-on/action#34

Full Changelog: runs-on/action@v2.1.0...v2.1.1

Commits

• e46a3c6 dist: rebuild binaries
• 88629fc Send runtime token to Magic Cache config
• 6e9cb2b Update actions
• 408de89 dist: rebuild binaries
• e8a2e6d Remove dead code: unused MetricSummary fields and calculateMin/calculateMax f...
• 3a86586 dist: rebuild binaries
• 61a7be1 build: upgrade to go 1.26
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[potiuk]

I think this one is pretty much absolutely no go. And I am surprised we have it ...

This action has embedded binary runner images (!!!) for differnet architectures? This sound super dangerous

[potiuk]

Holding off on approval pending a deeper look. verify-action-build's text-level checks pass cleanly (JS rebuild matches, lock file ✓, downloads verified, source diff is just +181/-118 LOC of real Go code from the maintainer), but runs-on/action ships binary/non-text artifacts at the release SHA that the scanners don't inspect line-by-line. Want to enumerate what's actually in the tag tree before signing off — will follow up with findings shortly.

[potiuk]

After deeper inspection: holding this as a recommended-reject pending upstream changes.

runs-on/action@v2.1.1 ships 10 MB of pre-compiled Go binaries directly in the repo (main-linux-amd64 3.6 MB, main-linux-arm64 3.2 MB, main-windows-amd64.exe 3.6 MB), built with go build -ldflags="-s -w" (strip symbols + DWARF) and then UPX-packed (upx -q -9) — explicitly compressed and obfuscated. The 2.2 KB index.js is just a launcher that exec's the appropriate platform binary via sudo -n -E (full preserved-env root on the runner). Release v2.1.1 has zero assets; the GitHub attestations API returns 404 for the binary blob SHA; there's no SLSA provenance, no checksums, no signatures.

verify-action-build's "JS rebuild matches" only covers the launcher — there is no part of our pipeline that proves the shipped binaries were built from the published source.

One additional concern worth flagging: the upstream Makefile has a dist: target that rebuilds binaries and immediately git commits them, with the comment "Used by Claude skills". There is no such org-wide convention — that comment reads like a prompt-injection trap aimed at coding agents that might run make dist from a verification flow. (I didn't run it.)

I'm filing an upstream issue at runs-on/action requesting actions/attest-build-provenance + signed release artifacts so future bumps can be verified via gh attestation verify. v2.1.0 is in the same shape and got approved on 2025-07-27 before this kind of inspection was routine — worth a retroactive re-review separately.

[potiuk]

Quick downstream-impact note before any retroactive-review decision: runs-on/action is actively used across the DataFusion family —

Repo	Workflows	Version	Refs
apache/datafusion	extended.yml, rust.yml	v2.1.0 (742bf56…)	16
apache/datafusion-comet	pr_build_linux.yml, spark_sql_test.yml	v2.1.0 (742bf56…)	7
apache/datafusion-sandbox	extended.yml, rust.yml	v2.0.3 (cd2b598…)	17

It's how they configure runs-on.com self-hosted runners for their perf/extended test matrix.

So:

• Rejecting v2.1.1 (this PR) doesn't break anyone today — nobody's adopted it yet.
• Retroactively rejecting v2.1.0 would break ~23 workflow references in datafusion + datafusion-comet. Before that conversation gets serious, worth looping in the DataFusion maintainers (@apache/datafusion-committers) so they're aware and can weigh in. They're the population that pays the cost.
• I've opened Add build provenance attestations + signed release artifacts so downstream consumers can verify binaries runs-on/action#36 asking upstream for SLSA attestations. If they ship them, the path forward is clean for everyone.