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
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 anerror
branch to test that Projects got deleted even when the test errored.