Our actions were using inputs in a way that wasn't as secure as it could be. The source of the problem would be on the side of our users - a bad actor triggering a workflow with a PR - so there's a lot more authors can do to help this situation than we can. Workflows triggered by pull requests are a specific place to watch. GitHub already has some default safeguards to prevent strangers, specifically first-time contributors, from triggering workflows like that. They can also set their org or repo to be more strict about pull requests from outside collaborators.
That said, we can do our part as well.
Also a couple other small fixes, like cleaning up (deleting) Projects the tests create.
Links to any solved or related issues
Closes #835, addresses #840 (the wrong example for action path)
Any manual testing I have done to ensure my PR is working
workflow_dispatch runs that uses tags correctly and an error branch to test that Projects got deleted even when the test errored.
In this PR, I have:
Reason for this PR
Our actions were using
inputsin a way that wasn't as secure as it could be. The source of the problem would be on the side of our users - a bad actor triggering a workflow with a PR - so there's a lot more authors can do to help this situation than we can. Workflows triggered by pull requests are a specific place to watch. GitHub already has some default safeguards to prevent strangers, specifically first-time contributors, from triggering workflows like that. They can also set their org or repo to be more strict about pull requests from outside collaborators.That said, we can do our part as well.
Also a couple other small fixes, like cleaning up (deleting) Projects the tests create.
Links to any solved or related issues
Closes #835, addresses #840 (the wrong example for action path)
Any manual testing I have done to ensure my PR is working
workflow_dispatchruns that uses tags correctly and anerrorbranch to test that Projects got deleted even when the test errored.