[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.