Verify SHA256 of downloaded LuaRocks tarball

[potiuk]

Context

This action currently runs:

const sourceTar = await tc.downloadTool(`https://luarocks.org/releases/luarocks-${luaRocksVersion}.tar.gz`)
await tc.extractTar(sourceTar, ...)
// configure / make / make install

with no integrity check on the downloaded tarball. A compromised mirror, an on-path TLS attack against an outdated runner, or accidental URL drift would silently install unverified code into a CI environment that often has package-publishing tokens, repository write tokens, or release-signing material in scope.

What this PR does

• Adds known-checksums.json mapping each supported LuaRocks version to its source-tarball SHA256.
• Adds a verifyTarball() step in main.js that runs immediately after tc.downloadTool and before tc.extractTar. If the downloaded SHA256 matches the recorded one, the action proceeds and prints a confirmation line. If it doesn't, or if the requested luaRocksVersion isn't in the dict, the action fails with a clear message pointing the user at the file to update.
• Updates the README to mention that luaRocksVersion must be listed in known-checksums.json and that adding a new version is a one-line PR.

Preseeded versions (each downloaded from https://luarocks.org/releases/ and sha256sum'd by hand): 3.13.0, 3.12.2, 3.12.1, 3.12.0, 3.11.1, 3.11.0, 3.10.0, 3.9.2.

Why a static dict, not a sidecar fetch

https://luarocks.github.io/luarocks/releases/ publishes detached PGP signatures (.tar.gz.asc) but no SHA256 sidecars. Two options were considered:

1. Verify the PGP signature at runtime — would require importing and trusting a signing key inside the action, plus running gpg on every supported runner OS. Adds a key-trust step that's hard to review.
2. Static SHA256 dict committed to the action repo (this PR) — reviewers can see exactly which versions the action will accept by reading one file. Adding a new version is a single-line PR. No additional runtime dependencies.

I went with (2) for simplicity. It's also the pattern used by similar setup-tool actions (e.g. actions/setup-node's manifest.json).

Why now

Apache Infrastructure runs an automated verifier (verify-action-build) on every Dependabot bump of a GitHub Action used across ASF projects. On the v6.0.0 → v6.1.0 bump (apache/infrastructure-actions#769) the verifier flagged this exact issue:

✗ main.js: 1 unverified JS download(s) (no checksum/signature check in file)
line 20: const sourceTar = await tc.downloadTool(\https://luarocks.org/releases/luarocks-\${luaRocksVersion}.tar.gz\`)`

That blocked auto-approval of an otherwise-valid bump, and the same pattern would re-block every future bump until the action gains some form of download verification.

Test plan

• node --check main.js passes (syntax).
• Spot-checked the SHA256 dict against a fresh download of luarocks-3.13.0.tar.gz from luarocks.org — match.
• Existing test workflow (.github/workflows/test.yml) on this PR — the default luaRocksVersion 3.13.0 is in the dict, so the test matrix should pass with the new check enabled.

Generated-by: Claude Opus 4.7 (1M context)