Skip to content

[PM-41997] [TEST] Test pull_request_target workflows from fork - #1387

Open
AmyLGalles wants to merge 3 commits into
bitwarden:mainfrom
AmyLGalles:add-pull-request-target-workflows
Open

[PM-41997] [TEST] Test pull_request_target workflows from fork#1387
AmyLGalles wants to merge 3 commits into
bitwarden:mainfrom
AmyLGalles:add-pull-request-target-workflows

Conversation

@AmyLGalles

Copy link
Copy Markdown
Contributor

Purpose

This is a TEST PR from a fork to validate that the new `*-target.yml` workflows function correctly for community PRs.

What to test

  1. ✅ The `build-android-target.yml`, `build-wasm-internal-target.yml`, and `enforce-labels-target.yml` workflows should trigger
  2. ✅ They should appear as `action_required` status
  3. ✅ A maintainer with write permissions must manually re-run them
  4. ✅ After re-run, the workflows should execute with secrets access

Note

This PR should be closed without merging after testing is complete. The actual changes are in PR #1386.

Adds companion -target.yml workflows to support community PRs that need
secrets access, following the established pattern from bitwarden/clients.

Problem:
Community PRs from forks fail when workflows require secrets (Azure auth,
GitHub App tokens, etc.) because fork PRs don't have access to repository
or organization secrets when triggered via pull_request events.

Solution:
Created three new -target.yml workflows that use pull_request_target:
- build-wasm-internal-target.yml
- build-android-target.yml
- enforce-labels-target.yml

These workflows:
1. Use check-run.yml to validate the triggering actor has write permissions
2. Only run for external forks (not internal PRs)
3. Call the existing workflows with secrets: inherit
4. Require manual approval - they show as "action_required" and must be
   re-run by a maintainer after code review

Security safeguards:
- No direct checkout of PR code (calls reusable workflows)
- Fork detection: github.event.pull_request.head.repo.full_name != github.repository
- Permission validation via check-run.yml
- Manual maintainer approval required before execution

Workflow for maintainers:
1. Community PR is opened
2. Workflows fail with "action_required" status
3. Maintainer reviews PR code for safety
4. Maintainer clicks "Re-run jobs" on failed checks
5. Workflows run with secrets access after permission validation

This follows the same pattern used in bitwarden/clients for
build-cli-target.yml, build-browser-target.yml, etc.
- Add workflow_call trigger to build-android.yml and build-wasm-internal.yml to make them reusable workflows
- Remove rc and hotfix-rc branch targets from build-wasm-internal-target.yml per linter requirement that pull_request_target can only target main branch
@AmyLGalles
AmyLGalles requested a review from a team as a code owner August 14, 2026 15:33
@AmyLGalles
AmyLGalles requested a review from dani-garcia August 14, 2026 15:33
Comment on lines +10 to +13
pull_request_target:
types: [opened, synchronize, reopened]
branches:
- main

@aikido-pr-checks aikido-pr-checks Bot Aug 14, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using unsafe GitHub Actions trigger may allow privilege escalation via CI/CD - critical severity
Using pull_request_target or workflow_run as a trigger is not recommended, as it may allow an attacker to elevate its privileges via the CI/CD pipeline by exfiltrating secrets (e.g. by reading out the caches of the GitHub Actions pipeline or listing loaded secrets in the environment). If the affected repository is open source, the attacker doesn't have to be an insider but could be any GitHub user.

Show fix
Suggested change
pull_request_target:
types: [opened, synchronize, reopened]
branches:
- main
pull_request:
types: [opened, synchronize, reopened]
branches:
- main

Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info

Comment on lines +10 to +13
pull_request_target:
types: [opened, synchronize, reopened]
branches:
- main

@aikido-pr-checks aikido-pr-checks Bot Aug 14, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using unsafe GitHub Actions trigger may allow privilege escalation via CI/CD - critical severity
Using pull_request_target or workflow_run as a trigger is not recommended, as it may allow an attacker to elevate its privileges via the CI/CD pipeline by exfiltrating secrets (e.g. by reading out the caches of the GitHub Actions pipeline or listing loaded secrets in the environment). If the affected repository is open source, the attacker doesn't have to be an insider but could be any GitHub user.

Show fix
Suggested change
pull_request_target:
types: [opened, synchronize, reopened]
branches:
- main
pull_request:
types: [opened, synchronize, reopened]
branches:
- main

Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info

@bitwarden-bot

Copy link
Copy Markdown
Collaborator

Thank you for your contribution! We've added this to our internal tracking system for review.
ID: PM-41997
Link: https://bitwarden.atlassian.net/browse/PM-41997

Details on our contribution process can be found here: https://contributing.bitwarden.com/contributing/pull-requests/community-pr-process.

@bitwarden-bot bitwarden-bot changed the title [TEST] Test pull_request_target workflows from fork [PM-41997] [TEST] Test pull_request_target workflows from fork Aug 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants