Safely and easily support CI checks on PRs from repo forks

[franknoirot]

This PR with no code changes was failing many required CI checks, which lead us to find that our repository is not set up well to accept PRs from repository forks, which is a very common contribution pattern in open-source.

This issue shed some light on other discussions, and led to this article from the GitHub Security Lab. There is some guidance there that I am trying to digest and map onto our repository's needs.

I am definitely not the best person to reason about the security implications of our GH Actions nor about how to reconfigure them to support external fork PRs in a safe manner, I just want to kick off the discussion so we can align on a course of action. I believe setting this up now will pay dividends in the future.

[franknoirot]

I should also say that I'm totally fine with the outcome of this discussion being to add a note to our CONTRIBUTING.md docs saying due to constraints we only accept PRs from permission-granted contributors.

[jessfraz]

Yes I think we need to whitelist thru github

[jessfraz]

I certainly don't want it that any joe shmo who opens a pr we've never encountered before gets access to CI, which is why by default github does that, and I think that is great

[franknoirot]

Yes I think we need to whitelist thru github

I totally support this, just don't want our seat count to explode. If there's a whitelist that doesn't add seats I'd love that.

[jessfraz]

no we whitelist CI this is a github built in ci doesnt run today unless you approve the contributor

[jessfraz]

you can read more here: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#controlling-changes-from-forks-to-workflows-in-public-repositories

[jessfraz]

they dont need to be in the org