Secrets Missing in Fork Pull Requests: Keep Release Credentials Out of Untrusted Builds

A fork pull request should be able to receive useful validation without receiving mobile signing or store-upload credentials. GitHub's secret restrictions are a trust boundary, not a broken configuration to bypass. Separate contribution checks from the workflow that builds and uploads a trusted release.

GitHub's secret-use guidance, checked October 8, 2026, explains that ordinary secrets are not passed to fork-triggered workflows, with the documented GITHUB_TOKEN exception. Reusable workflows and Dependabot events have their own availability considerations.

Name the code and event you trust#

Record the triggering event, source repository, checked-out revision and job permissions. A PR title or author association is not a complete assessment of the code the job will execute.

Classify each operation: static analysis, tests, unsigned build, signed archive, store upload or another external mutation. Only the latter operations normally need the relevant release credentials.

If the first failure is an unavailable secret, determine whether the job should need that secret on this event at all.

Design contribution checks without release credentials#

Use analysis, tests and compatible unsigned builds where the project supports them. Make the result explicit: an unsigned compile check does not establish production signing or store acceptance.

Keep the permissions and dependencies of those jobs narrow. Avoid printing secret expressions to diagnose availability. GitHub's documentation says an unset secret expression returns an empty string; handle unavailable configuration as a clear skipped release step or separate workflow rather than a confusing downstream authentication error.

Keep trusted release execution separate#

Run signing and uploads from the project's approved trusted event and revision, with its normal protected environment and authorization controls. Record exactly which source revision that release job builds.

Do not promote an untrusted artifact merely because a later privileged workflow can access it. The trust assessment must cover the artifact's producer and any code or executable inputs the release job will consume.

Similarly, a maintainer clicking a button is not proof that the code selected afterward is the revision they reviewed.

Avoid the target-event checkout trap#

GitHub's secure-use reference discusses risks around privileged workflows and untrusted inputs. Do not switch to pull_request_target and then execute the PR's code with release secrets simply to make a fork build pass.

The event's execution context and the source checkout are separate decisions. Review both, along with scripts, build hooks, actions and restored caches that can execute code.

Test the allowed and denied paths#

Use a designated non-production repository or safe synthetic configuration. Verify:

Fork PR: contribution checks run; no signing/upload access.
Trusted PR: intended checks run with the documented permissions.
Approved release revision: protected release workflow can run.
Missing release configuration: clear error; no credential output.
Untrusted artifact: not executed by a privileged release job.

These are proposed acceptance cases, not claims that your repository passed them. Do not request production credentials to demonstrate that a denial works.

Make the contributor result useful#

Explain which checks passed and which require the trusted release path. Avoid presenting skipped signing as a successful signed release.

For generated workflow edits, use our AI code review guide. Inspect event changes and permissions as carefully as shell commands; a convenient green workflow can conceal a broader security boundary change.