4 ms·

It's always been shocking to me that the way people run CI/CD is just listing a random repository on GitHub. I know they're auditable and you pin versions, but

It's always been shocking to me that the way people run CI/CD is just listing a random repository on GitHub. I know they're auditable and you pin versions, but it's crazy to me that the recommended way to ssh to a server is to just give a random package from a random GitHub user your ssh keys, for example. This is especially problematic with the rise of LLMs, I think. It's the kind of common task which is annoying enough, unique enough, and important enough that I'm sure there are a ton of GitHub actions that are generated from "I need to build and deploy this project from GitHub actions to production". I know, and do, know to manually run important things in actions related to ssh, keys, etc., but not everyone does.

sestep 2y ago
The crazier part is, people typically don't even pin versions! It's possible to list a commit hash, but usually people just use a tag or branch name, and those can easily be changed (and often are, e.g. `v3` being updated from `v3.5.1` to `v3.5.2`).
- harrisi 2y ago
  You and someone else pointed this out. I only use GitHub-org actions, and I just thought that surely there would be a "one version to rule them all" type rule.. how else can you audit things? I've never seen anything recommending specifying a specific commit hash or anything for GitHub actions. It's always just v1, v2, etc.
  - mcpherrinm 2y ago
    OpenSSF scorecard flags dependencies (including GitHub actions) which aren’t pinned by hash https://scorecard.dev/ https://scorecard.dev/ https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies https://github.com/ossf/scorecard/blob/main/docs/checks.md#p...
  - evntdrvn 2y ago
    it is documented as recommended here fwiw: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions https://docs.github.com/en/actions/security-for-github-actio...
    - sundarurfriend 2y ago
      And the syntax to do that is to use `foo/bar@commitshagoeshere` as in - uses: RafaelGSS/bad-action@e20fd1d81b3f403df56f5f06e2aa9653a6a60763 # v1.0.1 (example from https://blog.rafaelgss.dev/why-you-should-pin-actions-by-commit-hash https://blog.rafaelgss.dev/why-you-should-pin-actions-by-com...)
    - 0rzech 2y ago
      This. Using tags is acceptable only for official GitHub actions, anything else should be pinned.
- nextts 2y ago
  Fuck. Insecure defaults again. I argue that a version specifier should be only a hash. Nothing else is acceptable. Forget semantic versions. (Have some other method for determining upgrade compatibility you do out of band. You need to security audit every upgrade anyway). Process: old hash, new hash, diff code, security audit, compatibility audit (semver can be metadata), run tests, upgrade to new hash.
sieabahlpark 2y ago
[dead]
remram 2y ago
People don't pin versions. Referencing a tag is not pinning a version, those can be updated, and they are even with the official actions from GitHub.
- harrisi 2y ago
  Aren't GitHub action "packages" designate by a single major version? Something like checkout@v4, for example. I thought that that designated a single release as v4 which will not be updated? I'm quite possibly wrong, since I try to avoid them as much as I can, but I mean.. wow I hope I'm not.
  - remram 2y ago
    No the "v4" tag gets updated from v4.1 to v4.2 etc as those minor versions are released. They are branches, functionally.
    - harrisi 2y ago
      Wow, thank you (and the other person that pointed this out to me). That's madness.
      - semiquaver 2y ago
        You can pin actions to a git sha to prevent this but people generally do not. Action authors would prefer their updates be picked up automatically.
    - werrett 2y ago
      Exactly. And that's what happened here -- the bad actor changed all of those version tags to point to their malicious commit. See https://github.com/tj-actions/changed-files/tags https://github.com/tj-actions/changed-files/tags All the tags point to commit `^0e58ed8` https://github.com/tj-actions/changed-files/commit/0e58ed8671d6b60d0890c21b07f8835ace038e67#diff-3d2b59189eeedc2d428ddd632e97658fe310f587f7cb63b01f9b98ffc11c0197R2999 https://github.com/tj-actions/changed-files/commit/0e58ed867...
kalaksi 2y ago
So much this. I recently looked into using GitHub Actions but ended up using GitLab instead since it had official tools and good docs for my needs. My needs are simple. Even just little scripting would be better than having to use and audit some 3rd party repo with a lot more code and deps. And if you're new, and the repo aptly named, you may not realize that the action is just some random repo
tommasoamici 2y ago
Having to use actions for ssh/rsync always rubbed me the wrong way. I’ve recently taken the time to remove those in favor of using the commands directly (which is fairly straightforward, but a bit awkward). I think it’s a failure of GitHub Actions that these third party actions are so widespread. If you search “GitHub actions how to ssh” the first result should be a page in the official documentation, instead you’ll find tens of examples using third party actions.
12_throw_away 2y ago
> It's always been shocking to me that the way people run CI/CD is just listing a random repository on GitHub. Right? My mental model of CI has always been "an automated sequence of commands in a well-defined environment". More or less an orchestrated series of bash scripts with extra sugar for reproducibility and parallelism. Turning these into a web of vendor-locked, black-box "Actions" that someone else controls ... I dunno, it feels like a very pale imitation of the actual value of CI

sestep 2y ago

The crazier part is, people typically don't even pin versions! It's possible to list a commit hash, but usually people just use a tag or branch name, and those can easily be changed (and often are, e.g. `v3` being updated from `v3.5.1` to `v3.5.2`).

harrisi 2y ago
You and someone else pointed this out. I only use GitHub-org actions, and I just thought that surely there would be a "one version to rule them all" type rule.. how else can you audit things? I've never seen anything recommending specifying a specific commit hash or anything for GitHub actions. It's always just v1, v2, etc.
- mcpherrinm 2y ago
  OpenSSF scorecard flags dependencies (including GitHub actions) which aren’t pinned by hash https://scorecard.dev/ https://scorecard.dev/ https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies https://github.com/ossf/scorecard/blob/main/docs/checks.md#p...
- evntdrvn 2y ago
  it is documented as recommended here fwiw: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions https://docs.github.com/en/actions/security-for-github-actio...
  - sundarurfriend 2y ago
    And the syntax to do that is to use `foo/bar@commitshagoeshere` as in - uses: RafaelGSS/bad-action@e20fd1d81b3f403df56f5f06e2aa9653a6a60763 # v1.0.1 (example from https://blog.rafaelgss.dev/why-you-should-pin-actions-by-commit-hash https://blog.rafaelgss.dev/why-you-should-pin-actions-by-com...)
  - 0rzech 2y ago
    This. Using tags is acceptable only for official GitHub actions, anything else should be pinned.
nextts 2y ago
Fuck. Insecure defaults again. I argue that a version specifier should be only a hash. Nothing else is acceptable. Forget semantic versions. (Have some other method for determining upgrade compatibility you do out of band. You need to security audit every upgrade anyway). Process: old hash, new hash, diff code, security audit, compatibility audit (semver can be metadata), run tests, upgrade to new hash.

sieabahlpark 2y ago

[dead]

remram 2y ago

People don't pin versions. Referencing a tag is not pinning a version, those can be updated, and they are even with the official actions from GitHub.

harrisi 2y ago
Aren't GitHub action "packages" designate by a single major version? Something like checkout@v4, for example. I thought that that designated a single release as v4 which will not be updated? I'm quite possibly wrong, since I try to avoid them as much as I can, but I mean.. wow I hope I'm not.
- remram 2y ago
  No the "v4" tag gets updated from v4.1 to v4.2 etc as those minor versions are released. They are branches, functionally.
  - harrisi 2y ago
    Wow, thank you (and the other person that pointed this out to me). That's madness.
    - semiquaver 2y ago
      You can pin actions to a git sha to prevent this but people generally do not. Action authors would prefer their updates be picked up automatically.
  - werrett 2y ago
    Exactly. And that's what happened here -- the bad actor changed all of those version tags to point to their malicious commit. See https://github.com/tj-actions/changed-files/tags https://github.com/tj-actions/changed-files/tags All the tags point to commit `^0e58ed8` https://github.com/tj-actions/changed-files/commit/0e58ed8671d6b60d0890c21b07f8835ace038e67#diff-3d2b59189eeedc2d428ddd632e97658fe310f587f7cb63b01f9b98ffc11c0197R2999 https://github.com/tj-actions/changed-files/commit/0e58ed867...

kalaksi 2y ago

So much this. I recently looked into using GitHub Actions but ended up using GitLab instead since it had official tools and good docs for my needs. My needs are simple. Even just little scripting would be better than having to use and audit some 3rd party repo with a lot more code and deps. And if you're new, and the repo aptly named, you may not realize that the action is just some random repo

tommasoamici 2y ago

Having to use actions for ssh/rsync always rubbed me the wrong way. I’ve recently taken the time to remove those in favor of using the commands directly (which is fairly straightforward, but a bit awkward). I think it’s a failure of GitHub Actions that these third party actions are so widespread. If you search “GitHub actions how to ssh” the first result should be a page in the official documentation, instead you’ll find tens of examples using third party actions.

12_throw_away 2y ago

> It's always been shocking to me that the way people run CI/CD is just listing a random repository on GitHub. Right? My mental model of CI has always been "an automated sequence of commands in a well-defined environment". More or less an orchestrated series of bash scripts with extra sugar for reproducibility and parallelism. Turning these into a web of vendor-locked, black-box "Actions" that someone else controls ... I dunno, it feels like a very pale imitation of the actual value of CI