Add rubygems/release-gem to allowlist

[kpumuk]

Request for adding a new GitHub Action to the allow list

Overview

Add rubygems/release-gem to the allowlist. This is the official trusted publishing action maintained by the RubyGems team, see Releasing gems with a trusted publisher.

At Apache Thrift we want to switch to trusted publishing to remediate supply chain risk, but I believe the workflow will be blocked until the action is allowlisted. See https://github.com/apache/thrift/blob/master/.github/workflows/release_ruby.yml

Name of action:

rubygems/release-gem

URL of action:

https://github.com/rubygems/release-gem

Version to pin to (hash only):

6317d8d1f7e28c24d28f6eff169ea854948bd9f7

Permissions

id-token: write

Related Actions

• rubygems/configure-rubygems-credentials@bc6dd217f8a4f919d6835fcfefd470ef821f5c44 # v1
  https://github.com/rubygems/release-gem/blob/v1/action.yml#L58C13-L58C93

Checklist

You should be able to check most of these boxes for an action to be considered for review.
Please check all boxes that currently apply:

• The action is listed in the GitHub Actions Marketplace
• The action is not already on the list of approved actions
• The action has a sufficient number of contributors or has contributors within the ASF community
• The action has a clearly defined license
• The action is actively developed or maintained
• The action has CI/unit tests configured
• Compiled JavaScript in dist/ matches a clean rebuild (verify with uv run utils/verify-action-build.py org/repo@hash)

[potiuk]

The verify check is failing on a false positive in the binary-download heuristic — flagging it here and proposing a follow-up.

The two flagged files (src/oidc/assumeRole.ts, src/oidc/trustedPublisher.ts) aren't in rubygems/release-gem itself — that's a composite action. The verify script transitively followed the uses: rubygems/configure-rubygems-credentials@bc6dd217... step into the node20 helper action, which is where those files live.

What they actually do: POST a GitHub OIDC token to a RubyGems.org endpoint via @actions/http-client's postJson, get back a short-lived API key, and validate it through a Zod schema. Same shape as AWS STS AssumeRoleWithWebIdentity — the response is the credential; nothing is downloaded, written, or executed.

Our heuristic flags new HttpClient(...) as a potential unverified download but didn't yet recognize the *Json helpers (postJson, getJson, etc.) as an explicit "treat the response as structured data" signal. Follow-up PR adding them to the data-parse exemption list, with a regression test using the exact pattern from this action: #790

Once that lands, this PR's verify check should pass on a re-run. The action itself looks fine on policy grounds — OIDC trusted publishing is the entire mechanism for avoiding static credentials.

[potiuk]

I think it's safe to merge (see above) - I will merge it tomorrow if there are no objections).

[kpumuk]

Thank you! We are going to pin SHA and add the workflow to validate actions agains the allowlist apache/thrift#3437

[potiuk]

Merging !

[potiuk]

Thank you! We are going to pin SHA and add the workflow to validate actions agains the allowlist apache/thrift#3437

Cool. I see you used the allowlist action ! Fantastic :).