ci: pin gem-push workflow actions to immutable commit SHAs

[07souravkunda]

What

Pin the three GitHub Actions used by .github/workflows/gem-push.yml to full 40-character
commit SHAs instead of mutable version tags:

Action	Before	After
actions/checkout	@v3	@c85c95e3d7251135ab7dc9ce3241c5835cc595a9 # v3.5.3
ruby/setup-ruby	@v1	@a0102e0972be65f351c307e2d64b9314a57c8073 # v1.324.0
rubygems/configure-rubygems-credentials	@v2.0.0	@762a4b77c3300434bb57c7ce80b20e36231927aa # v2.0.0

Why

gem-push.yml publishes the gem to RubyGems.org (OIDC trusted publishing, id-token: write).
Resolving its actions from mutable tags means a hijacked or force-pushed upstream tag could
redirect the executed action code into the publish job — a supply-chain injection risk
(CWE-829, per GitHub's Actions hardening guidance).
Pinning to an immutable commit SHA removes that redirection. This matches the pattern the
repo's own Semgrep.yml already uses (it pins actions/checkout to the same v3.5.3 SHA).

Notes

• Each pinned SHA is the commit the corresponding tag resolves to today, so the publish job's
  behaviour is unchanged (same checkout, same Ruby 2.6.10 setup, same credentials action).
• Enabling Dependabot for the github-actions ecosystem is recommended to keep these SHAs
  updated automatically.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited), Workspace UI (inherited)

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 3c87d2b3-791b-45c4-85fc-f866258ab950

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[07souravkunda]

Pipeline security review (round 0) — WI-72531096 · reviewer: stack:local-security-review-auto

Verdict: no blocking findings. The diff is a clean, correctly-scoped SHA-pin of the three actions in gem-push.yml, matching the repo's own Semgrep.yml convention. One non-blocking wording nit inline.

Security gates:

• S0 (no internal id leaked, public repo): pass — no LOC-/SC- id in title, body, commits, or diff; described by CWE-829.
• S1/S4 (pins resolve correctly): pass — all three SHAs verified against their upstream tags both directions (checkout v3.5.3=c85c95e, setup-ruby v1.324.0=a0102e0, configure-rubygems-credentials v2.0.0=762a4b7).
• S2 (no drive-by): pass — diff is exactly the three uses: pins, nothing else.
• S3 (manifest↔lockfile): n/a — no manifest in this PR.
• S4c (chain): pass — C-003 breaker (F-013) fixed here; C-002 breaker (F-012) correctly routed to the already-approved human-owned PR #42 (verified: non-draft, APPROVED, makes the http://→https:// + CHECKSUMS change), not a competing Gemfile change; all 5 batch tickets have posted routing/dispute comments; residual F-023 truthfully stated as already-remediated on master (OIDC trusted publishing).
• S5 (testing): pass — CI-config-only change; static validation (YAML parse + pin lint + upstream-SHA confirmation) is the complete accepted result, no gem-push trigger (would publish a real gem), no regression test (correct for a pin), human-verify handoff provided.

Keeping this a Draft; a human owns approval and merge.

[07souravkunda]

[nit] The PR description says "each pinned SHA is the commit the corresponding tag resolves to today." That's exact for ruby/setup-ruby (@v1 → a0102e0 / v1.324.0) and configure-rubygems-credentials (@v2.0.0 → 762a4b7), but not for actions/checkout: @v3 currently resolves to a37ce91… (v3.6.0), whereas this pins c85c95e… (v3.5.3). Pinning v3.5.3 is a deliberate, good choice — it matches the SHA the repo's own Semgrep.yml already pins, and v3.5.3→v3.6.0 is immaterial to gem build/gem push — so no code change is needed. Just consider tightening the wording (e.g. "SHAs are known-good tag versions; checkout is pinned to the same v3.5.3 as Semgrep.yml") so a future reader isn't surprised it isn't the current @v3 tip. Non-blocking.