[PM-41997] [TEST] Test pull_request_target workflows from fork - #1387
[PM-41997] [TEST] Test pull_request_target workflows from fork#1387AmyLGalles wants to merge 3 commits into
Conversation
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
| pull_request_target: | ||
| types: [opened, synchronize, reopened] | ||
| branches: | ||
| - main |
There was a problem hiding this comment.
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
| 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
| pull_request_target: | ||
| types: [opened, synchronize, reopened] | ||
| branches: | ||
| - main |
There was a problem hiding this comment.
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
| 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
|
Thank you for your contribution! We've added this to our internal tracking system for review. Details on our contribution process can be found here: https://contributing.bitwarden.com/contributing/pull-requests/community-pr-process. |
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
Note
This PR should be closed without merging after testing is complete. The actual changes are in PR #1386.