There's an important distinction between "privileged" and "unprivileged" Workflow Runs, and the context within which a Workflow is executed.
Let's imagine there's a repository containing a Workflow (on the branch) that listens to the `push` event and then outputs the value of `secrets.API_KEY`:
* A collaborator pushes: Workflow Run is privileged -> the value of `secrets.API_KEY` is output
* A non-collaborator pushes: Workflow Run is unprivileged -> no value is output
The `pull_request_target` event type comes into play when you need a privileged Workflow Run to execute when a non-collaborator performs an action. For security, `pull_request_target` events are only triggered against a Workflow on the primary repository branch, a non-collaborator cannot sneak a `pull_request_target` into their Pull Request. Essentially, `pull_request_target` in a Workflow on your main branch is "listening" for Pull Requests.
There is no risk using `pull_request_target` if you do not execute any code from the Pull Request within a privileged Workflow. If you execute code from the Pull Request within a privileged Workflow, then you're definitely exposed to a lot of serious problems.
* An unprivileged Workflow Run should... build artifacts, execute tests, upload artifacts to the Workflow Run
* A privileged Workflow Run should... download artifacts from the unprivileged Workflow Run, publish artifacts to storage
> Has modifying the workflow on a 'PR branch' only worked for me because I've been the repo owner perhaps?
Every time you execute a Workflow as a repository owner, it is privileged and can do anything. For example, your Pull Request Workflow Run can access secrets (so you might think that _all_ Pull Requests can access secrets) but in reality, a Pull Request from a non-collaborator cannot.
Does that help clarify? The security model of GitHub Actions has changed over the last year, so it's not completely intuitive if your frame of reference is from before the changes. I highly recommend the GitHub Security blog articles, they're very illuminating.
I love GitHub Actions, so much so I’ve published lots of Actions on the Marketplace. I love that I can contribute to better pipelines for all.
That said, I have frustrations with the management of the GitHub Actions repositories: which is to say, there isn’t any. Most issues and Pull Requests languish, without acknowledgement or engagement.
I appreciate that managing issues and contributions is a full time job, and your team probably doesn’t have capacity right now: if you could magic up some capacity, that would be great, but… a more realistic request would be to evaluate capacity and follow Terraforms lead in being open about pausing contributions —- rather than READMEs that encourage contributions, which (despite the best of intentions) will never be reviewed.
Let's imagine there's a repository containing a Workflow (on the branch) that listens to the `push` event and then outputs the value of `secrets.API_KEY`:
* A collaborator pushes: Workflow Run is privileged -> the value of `secrets.API_KEY` is output
* A non-collaborator pushes: Workflow Run is unprivileged -> no value is output
The `pull_request_target` event type comes into play when you need a privileged Workflow Run to execute when a non-collaborator performs an action. For security, `pull_request_target` events are only triggered against a Workflow on the primary repository branch, a non-collaborator cannot sneak a `pull_request_target` into their Pull Request. Essentially, `pull_request_target` in a Workflow on your main branch is "listening" for Pull Requests.
There is no risk using `pull_request_target` if you do not execute any code from the Pull Request within a privileged Workflow. If you execute code from the Pull Request within a privileged Workflow, then you're definitely exposed to a lot of serious problems.
* An unprivileged Workflow Run should... build artifacts, execute tests, upload artifacts to the Workflow Run
* A privileged Workflow Run should... download artifacts from the unprivileged Workflow Run, publish artifacts to storage
> Has modifying the workflow on a 'PR branch' only worked for me because I've been the repo owner perhaps?
Every time you execute a Workflow as a repository owner, it is privileged and can do anything. For example, your Pull Request Workflow Run can access secrets (so you might think that _all_ Pull Requests can access secrets) but in reality, a Pull Request from a non-collaborator cannot.
Does that help clarify? The security model of GitHub Actions has changed over the last year, so it's not completely intuitive if your frame of reference is from before the changes. I highly recommend the GitHub Security blog articles, they're very illuminating.