GitHub actions while very flexible are also prone to ask kinds of problems.
E.g. versions of actions on the market place are not pinned so people can republish different code under the same version. So you need to pin to a git commit hash which is much easier to get wrong and also easier to abuse for social engineering. And that's assuming you trust git commit hashes, if not you need to fork actions just to make sure the public code you reviewed doesn't get changed without new reviewes .
I've recently started using GitHub Actions and I was very disappointed to learn how few "native" actions there are. I don't want to introduce yet another avenue of third-party code via the GitHub Actions marketplace.
My GH workflows are a thin layer over the `run` action that runs shell scripts. Not only does my CI not have to rely on third-party actions, it's also extremely portable between CI providers, can be tested locally, and is infinitely more flexible.
(Apart from having run actions, the only other actions I use are the upload/download-artifact ones to share binaries between jobs, and the matrix feature for parallelizing runs.)
But to be clear, the kind of vulnerability that the P0 issue is talking about is not necessarily from malicious actions. As the issue itself says, the vuln also happens from untrusted input being processed by a trusted action, like issues and PRs.
This is what every build should be. If I can't build it locally and in CI using the same process, I consider it broken. I tend to use Makefile, but what your describing is what I consider best practice.
I did create a a couple of simple actions which abstract this a little, but I agree it is best when everything is in the repository and self-contained.
So I have a "run tests" action which just executes .github/run-tests, and it is up to the project-owner to write "make test" in that script, or whatever else they prefer.
It keeps things well-defined, and portable, but avoids the need to have project-specific workflows. I like being able to keep the same .yaml files in all my projects.
This is something I found when looking at GitHub actions. I don't want to use tons of third party stuff and be vendor locked in. We already moved builds to build a Docker container when we used Travis for this exact reason before testing with CI.
I played around with some actions wrt. commit signing and originally wrote a action a verify commit and tag signatures (in the way I need ;=) ). But now I plan to port it to a more general interface I can call from a GH action.
Right so that enables a potential hacker to set an env variable, which has to in a later step get picked up by another cli tool that uses the env variable in such a way that the contents of the env variable gets executed as code.
So interpreters like node/ruby/perl etc could execute the malicious stuff in the env variables. Are there any other cli tools that could do something dangerous?
> versions of actions on the market place are not pinned so people can republish different code under the same version
It's a feature, not a bug. When I publish my Actions, I publish them at `v1.2.3`, `v1.2`, and `v1`. Since Action authors using the `@actions/core` API had to update them on 1 Oct, users consuming a `@v1` release tag across their hundreds of repos/Workflows don't need to make any YAML changes at all to get the updated Actions.
It's IMHO a misguided way to archive that feature.
The way this provides semver like behaviour is IHMO just a hack, one which requires a bunch or additional work, too.
Instead when releasing a version to the marked place that code should be pinned/copied by github.
Then versions should be resolved by semver to get the effect you mentioned without needing to publish additional redundant tags (which are easy to get wrong).
Then you could just specify a action as `=1.2.3` to be sure to get the code you reviewed at any point in the future and if you trust the author you use e.g. `^1` to get any `1.x.y`.
Don't get me wrong the current way does work, is easier for github and sidesteps the whole "what counts as semver" discussion ;=)
Still it's IMHO suboptimal, it's really easy to e.g. forget to move one of the tags and it's also a problem for the "review and pin reviewed" version approach as instead of "=1.2.3" you now need to find to commit of that tag and use that, which also means in you workflow it's no longer obvious without comments which version you run with all the problems that implies.
It's the simplest way for github to archive a system which seems to work well in general.
Then they throw it at the community and hope that any rough edges/problems are overshadowed by the hype around it and by cool thinks people do with it. Then they can slowly incrementally fix it with "live" feedback.
Ironically while this might seem bad long term it can potentially lead to a better end-product from both the view of github and the users.
The only problem is that you run at risk of ossification, i.e. you no longer being able to fix a problem because to many rely on it being that way.
GitHub actions while very flexible are also prone to ask kinds of problems.
E.g. versions of actions on the market place are not pinned so people can republish different code under the same version. So you need to pin to a git commit hash which is much easier to get wrong and also easier to abuse for social engineering. And that's assuming you trust git commit hashes, if not you need to fork actions just to make sure the public code you reviewed doesn't get changed without new reviewes .