[natfriedman]

The mitigations you suggest are all logical. However, there are legitimate reasons to run CI and tests for outside contributions without taxing maintainers with the cognitive load of having to evaluate whether each contribution is CI-worthy.

The attack vector in the article is not the main way miners try to steal CPU from the GitHub community. It's just an interesting one that the journalist chose to write about.

[teachtwolearn]

But when a PR is submitted that modifies an Actions workflow, shouldn't GitHub run the old unmodified workflow until that PR is accepted?

IIRC, they already treat the .github folder as a special case; you can't push modifications to workflow files with a personal access token. So why not ensure that an action or workflow will only run if it is checked into the base branch?

That wouldn't stop PRs from modifying scripts that the action runs, but the current behavior seems a bit counter-intuitive.

[lmeyerov]

If that action is "./run_tests.sh", which is a top use case, the attacker just changes "./run_tests.sh", so while I agree that's useful, it doesn't secure the typical case, and makes for a hard cost/value stance.

The threat models are probably more like 1. "make sure only the right people run actions" and separately, 2. "make sure authorized events/actions only use the expected capabilities." Both largely fail today.

[cortesoft]

Well the idea is that a person submits a PR, and the action runs to verify that the tests pass BEFORE the PR is accepted. You don’t want to wait until after the code is merged in order to see if tests still pass.

The issue is that even if you don’t allow changes to the actual action workflow, running tests gives an attacker the ability to run arbitrary code. They just need to add the code they want to run to the tests (e.g. have the tests mine crypto)

[wiredfool]

That makes it really hard to debug actions, and ensure that they’re working prior to merging.

[neolog]

> steal CPU from the GitHub community

from Microsoft*