4 ms·

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

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.

Arnavion 6y ago
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.
- bastardoperator 6y ago
  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.
- dathinab 6y ago
  I plan to do something similar soon ;=) 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.
- brainbag 6y ago
  Is your github workflow source available?
  - Arnavion 6y ago
    https://github.com/Arnavion/fac-rs/tree/master/.github/workflows https://github.com/Arnavion/fac-rs/tree/master/.github/workf... https://github.com/Arnavion/k8s-openapi/tree/master/.github/workflows https://github.com/Arnavion/k8s-openapi/tree/master/.github/...
- stevekemp 6y ago
  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. https://github.com/skx/github-action-tester https://github.com/skx/github-action-tester Similar thing for building and uploading artifacts, run ".github/build" and specify the glob-pattern for your artifacts: https://github.com/skx/github-action-build https://github.com/skx/github-action-build
- mjgs 6y ago
  Yeah the fact that the untrusted inputs can come from PRs and Issues is worrying. I totally had not considered that. I’m still a bit unclear how that could happen in practice thought. So the PR/Issue text would need to be written to stdout?
  - Arnavion 6y ago
    >I’m still a bit unclear how that could happen in practice thought. So the PR/Issue text would need to be written to stdout? Yes. The issue title (the two actions the P0 issue talks about both do this) or the text, and same for PRs.
    - mjgs 6y ago
      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?
- physicsguy 6y ago
  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.
ameliaquining 6y ago
By "native", do you mean first-party? Surely there are other third parties besides GitHub that you'd entrust with an API token.
ashtonkem 6y ago
The moment I realized how many actions in GitHub required running untrusted code I went back to CircleCI.

Arnavion 6y ago

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.

bastardoperator 6y ago
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.
dathinab 6y ago
I plan to do something similar soon ;=) 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.
brainbag 6y ago
Is your github workflow source available?
- Arnavion 6y ago
  https://github.com/Arnavion/fac-rs/tree/master/.github/workflows https://github.com/Arnavion/fac-rs/tree/master/.github/workf... https://github.com/Arnavion/k8s-openapi/tree/master/.github/workflows https://github.com/Arnavion/k8s-openapi/tree/master/.github/...
stevekemp 6y ago
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. https://github.com/skx/github-action-tester https://github.com/skx/github-action-tester Similar thing for building and uploading artifacts, run ".github/build" and specify the glob-pattern for your artifacts: https://github.com/skx/github-action-build https://github.com/skx/github-action-build
mjgs 6y ago
Yeah the fact that the untrusted inputs can come from PRs and Issues is worrying. I totally had not considered that. I’m still a bit unclear how that could happen in practice thought. So the PR/Issue text would need to be written to stdout?
- Arnavion 6y ago
  >I’m still a bit unclear how that could happen in practice thought. So the PR/Issue text would need to be written to stdout? Yes. The issue title (the two actions the P0 issue talks about both do this) or the text, and same for PRs.
  - mjgs 6y ago
    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?
physicsguy 6y ago
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.

ameliaquining 6y ago

By "native", do you mean first-party? Surely there are other third parties besides GitHub that you'd entrust with an API token.

ashtonkem 6y ago

The moment I realized how many actions in GitHub required running untrusted code I went back to CircleCI.