A trust paradox
Last month, I wrote about how to define, build, and measure trust in your community. Here’s the challenge: you need to extend trust in order for someone to build trust. I touched on this in 2023 after an Ubuntu release included hate speech in translations. It came back to the fore earlier this month after an AI agent attacked a handful of high-profile GitHub repositories.
The agent took advantage of workflows that allowed an attacker to run malicious code via a variety of mechanisms, including the branch name. The attacking agent only needed to open a pull request to cause damage. Normally, tests run by CI infrastructure are a way to evaluate the trustworthiness of a pull request. Most pull requests, of course, are not malicious, but that doesn’t make them trustworthy. A change that fails linting, unit tests, or integration tests may not be worth a maintainer’s time to review.
So if automated CI tests are both a way to measure trust and a vector for attack, what’s the responsible maintainer to do?
The first step is to make sure your CI jobs are securely configured. Tools like zizmor can identify insecure configurations. You may also want to require that a maintainer manually approve workflows before running against pull requests from untrusted sources. This, of course, puts you into a position where you now have to at least give a cursory review to make sure the change is safe enough for your CI workflow. But that’s less work than a detailed review.
With the rise in AI-generated pull requests, this is a problem that will only add more toil for maintainers. Hopefully, platforms will provide tools that reduce the burden.
