I just meant the people saying it is crazy to allow anons to do something to run CI vs the people saying it is crazy to make me look at a PR before CI has blessed it. The prior assessment of value to an anon PR is -1 for the former, Cathedral folks, and +1 for the latter, Bazaar folks. I don’t know if FSF even now has CI but I think you have to sign paper work of copyright assignment before they consider your PR, more or less. While rando GitHub repos will take even my PRs.
If I could wave my wand no build or deploys would need to talk to the internet. We want that all to be deterministic and based on resources we control. But that battle is lost. But white listing software depos and so on seems winnable still.
It also mirrors the “unit tests / CI should be self-contained with network deps mocked” vs “it isn’t tested till it is integration tested” debate. The mock/unit test folks don’t need the network access in CI. Even the clever integration testers can spin up a DB and a local Hadoop cluster during the tests. Only the busy, harried integration testers need the real system to test against during CI. (Disclaimer I have written tests of all three kinds).
Ah, right. I'm in the camp of "Why not both?" for OSS public PRs: Make it safe for CI on external pulls by external users. To support the disneyification of security / smart defaults, make an easy button to infer the policy per workflow, such as based on the last X runs. However, instead of today's unsafe and chaotic set of checkbox rules & enforcements, tie that to an RBAC policy over user/role x workflow x capability, and cover the usual suspects of physical + logical resources that virtual & data envs typically protect.
Ex: I'd expect the typical inferred public PR CI policy to be no creds/keys, a fixed set of network URL regexes (package deps like https://npm/@trusted_org/\*), upperbounds on CPU/memory/network/disk/etc, and ~no use of internal github APIs. There's probably surprises like `apt-get update`, which in turn is probably addressable with some common special cases. Likewise, for failure modes, as long as no creds are there and resource quotas are in place, most orgs are probably ok to make network read violations be WARN instead of HALT.
That probably covers the 90-99% case when making public PR workflows much safer.
For internal teams and higher-trust actions (CD, issue bots, ...), I'd expect the same but different. Currently, I'm not really sure how to do something like "Add a contractor but keep them away from most things" except by setting up a second repo with just CI. If there was RBAC and policy inference, however, that'd be all of 2 minutes.
If I could wave my wand no build or deploys would need to talk to the internet. We want that all to be deterministic and based on resources we control. But that battle is lost. But white listing software depos and so on seems winnable still.
It also mirrors the “unit tests / CI should be self-contained with network deps mocked” vs “it isn’t tested till it is integration tested” debate. The mock/unit test folks don’t need the network access in CI. Even the clever integration testers can spin up a DB and a local Hadoop cluster during the tests. Only the busy, harried integration testers need the real system to test against during CI. (Disclaimer I have written tests of all three kinds).