Thanks! Then I suggest to change wording in documentation to be less scaring, and maybe add validation in runner which prints big bold warning whenever self-hosted runner is triggered in PR event in public repo.

I’m not sure this is safe. What happens if someaone creates a PR modifying the workflow to run on pull_requests?

Once a repo has been forked you aren’t in control of changes on the fork right? So it seems fine to me as long as the malicious code is not run on the main repo

We’re investigating using self hosted runners at my work, but we’ve got hundreds of public repos so this issue is quite a blocker for us - something like @kousu suggests where you can prevent forked repos using self hosted runners at an organisation level would be very helpful.

What with a situation, where we have a public repository and would like to run the tests with some physical device, e.x. webcamera?
My original thought was to create a self-hosted runner and attach the device physically to it, but as the docs specified, it’s dangerous to use self-hosted instances on public repositories.
Are there any alternatives?

I am sorry to tell you that there is no alternatives. To test with physical device , you need to use self-hosted runner.
If it is possible for you, I would suggest you to use a private repo.

I think a good feature is if in the future we could trigger a workflow when an authorised user comments on an open PR. At the current moment it is hard to see how to deploy a self hosted runner in my development as ideally I would like to run CI before I push any new code to any of my branches.

Yeah I like the suggestion from @bdevierno1 . I would be great if the action can be triggered only by comment (e.g. /test) that is coming from one of the people that are part of the OWNERS file. Would that be possible?

or

what about blocking merging unless 1 approval from an owner is required? If that’s the case I would be great to have an action that can be triggered based on the “approved” status of a PR.

I think it would also be useful to have different event types for “internal” and “external” pull requests, where “internal” means pull request originates from the same repo with workflow. If workflow is triggered by internal PRs only it would require having write access to repo to run code on self-hosted runner.

But isn’t it more dangerous that was discussed before in this thread?

According to this thread How to prevent GitHub Actions workflow being triggered by a forked repository events? - Stack Overflow if you have a self-hosted runner, than anyone can create a workflow that targets self-hosted runner and create a PR.

This will trigger the workflow to be executed on a self-hosted runner even if you haven’t accepted the PR?

You are correct, I tested this myself.

The conditions for a potential security breach are like so:

• The repo is public
• Any self-hosted runner is accessible in the repo (either via repo or organisation settings)
• The repo has defined at least one workflow file with pull_request trigger
• The repo maintainer has not checked Require approval for all outside collaborators

Then a malicious actor can simply open a PR from a forked repo where they add a new workflow file like so:

name: Malicious Workflow
on:

pull_request:

branches: [ main ]
jobs:

malicious-job:

runs-on: self-hosted
steps:
  - name: Run a malicious script
    run: |
      echo Malicious script running from **forked** repo

The script will run on the available self-hosted runner of the maintainer’s repo.

The best (and most cumbersome) way to prevent this is to check Require approval for all outside collaborators in the repo settings as explained here. Then you have to manually approve workflows running on each PR, after you have first checked the PR for any changes to workflow files.

Another way to mitigate the risk would be to have a private “companion” repo to your public repo that the self-hosted runner is assigned to as explained here but I haven’t tried this myself.

I don't understand what is not safe about running on self hosted when it's not a fork, but a commit to a branch or PR from a branch on the same repository. And I thought there were already such conditionals in the case of github actions secrets.

In order to protect public repositories for malicious users we run all pull request workflows raised from repository forks with a read-only token and no access to secrets.

https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

I'm using a standard GitHub provided runner for PRs where it runs tests and validates that a Linux build passes.

For releases I build binaries in my pipelines and publish them to a github release. Right now I am using on: workflow_dispatch but I may soon move to on: push: branches: ['main'].

1. Can I use a self hosted runner safely on a public repo with a workflow_dispatch setting?
2. Can I use a self hosted runner safely on a public repo with a [workflow_dispatch](on: push: branches: ['main']) setting?