> A big ugly warning in the UI?
There's already a warning in the docs. There's no UI to put the warning in that isn't going to be visible until it's too late. And even that warning isn't scary enough - this documentation is buried behind a "warning" in the docs and then two more links to get to the meat.
> Workflows triggered via pull_request_target have write permission to the target repository. They also have access to target repository secrets. The same is true for workflows triggered on pull_request from a branch in the same repository, but not from external forks. The reasoning behind the latter is that it is safe to share the repository secrets if the user creating the PR has write permission to the target repository already.
> pull_request_target runs in the context of the target repository of the PR, rather than in the merge commit. This means the standard checkout action uses the target repository to prevent accidental usage of the user supplied code.
So what this means is if you use `pull_request_target`, the jobs have read and write access to privileged data in the repo (including secrets) and the code the job runs is controlled by the target.
> Or, push back on the architecture?
Personally, I would advocate to remove this feature for public repositories. It has ~zero legitimate use cases. If it needs to come back, it should be an error to run jobs on this trigger if the user that initiated it doesn't have write permissions for the repo.
If this breaks CI pipelines that is a good thing. Those pipelines are just waiting to be pwned.
There's a PR open to mitigate this on actions/cache but I don't believe it's actually solving the root cause, which is in the design of actions itself.
