Wouldn't this be as simple as restricting CI until the repo owner has looked over the PR?

It's moving the problem but at the end of the day the repo owner has to look over and choose to accept or reject the PR.

What would stop someone submitting a PR that updates the workflow trigger to run immediately? It feels like this in more of a fundamental problem with "Putting your CI definition alongside your code".

I seem to remember that a CI run for a PR takes the workflow file from the HEAD of the branch, rather than master. But I'd have to check.

Github disables secrets for actions triggered from pr's. But users can commit an action that runs on their pr.

The maintainer would reject such a PR? Even if the CI run takes from the HEAD it would still be the responsibility for the repo owner to not allow the PR to be run in the first place.

But the trigger for the run in defined in the workflow file.

So even if you have a workflow that requires a manual trigger, I can just fork, and create a PR that updates that trigger to be `pull_request` and the workflow will run as soon as I create the PR. I don't need the PR to be accepted before I can start running arbitrary code on your self-hosted runner.

Or am I missing something?

Perhaps I did not explain clearly, your PR does not automatically run the workflow.

Perhaps it would be more clear to imagine two files, a workflow file describing the CI steps and a permission file describing what can trigger the CI.

The CI will use the permission file from the last trusted commit (which would also be the last commit that the CI was run on) but uses the workflow file of the current commit.

In your case you create a PR that updates both the workflow and permissions file. The CI sees that the previous trusted commit requires that I, the repo owner has to manually submit unknown PRs to the CI. Seeing that your PR is malicious, I don't submit the PR to the CI.

Now that I've layed it out explicitly I realise that the non intuitiveness comes from using git to track CI configuration in the same repo.

we don't, but even for our public repos, our first action is to only allow maintainers to run checks

Sandboxed containers.

In Facebook for example, in the internal network you can access a lot of machines without authentication (let's say you open a PR to one of their public repo, and this runs in their internal network), and of course the beta of Facebook.

I don't think "self hosted" has to mean "can access some special internal network". Just put a Threadripper under your desk. Have a coworker do the same for disaster recovery / high availability :)