3 ms·

Some people do actually pin versions, like me. For instance: - uses: Swatinem/rust-cache@f0deed1e0edfc6a9be95417288c0e1099b1eeec3 # v2.7.7 or - uses: sub

by 0rzech 2y ago

Some people do actually pin versions, like me. For instance: - uses: Swatinem/rust-cache@f0deed1e0edfc6a9be95417288c0e1099b1eeec3 # v2.7.7 or - uses: subosito/flutter-action@f2c4f6686ca8e8d6e6d0f28410eeef506ed66aff # v2.18.0 It's a bit more manual work, but lepiej dmuchać na zimne (lit. it is better to blow on something cold), as the Polish proverb says.

brokenpip3 2y ago
>It's a bit more manual work after this incident, I started pinning all my github workflows with hashes, like other folks here I guess :D But I quickly got tired of doing it manually so I put together this [0] quick and dirty script to handle it for me. It just updates all workflow files in a repo and can be also used as a pre-commit hook to catch any unpinned steps in the future. It’s nothing fancy (leveraging ls-remote), but it’s saved me some time, so I figured I’d share in case it helps someone else :) [0] https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov-file#github-actions-hash https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov...
- 0rzech 2y ago
  > github action dependency with the hash of the specific tag and a human readable tag that dependabot will keep/update in the future [1] Allowing bots to do that is going to make you vulnerable to such attacks anyway. [1] https://github.com/brokenpip3/pre-commit-hooks/blob/f01df657bd43b5043994cf981b216374c15f6ef3/README.md#github-actions-hash https://github.com/brokenpip3/pre-commit-hooks/blob/f01df657...
matsemann 2y ago
You would still be exposed if you had renovate or dependabot make a PR where they update the hash for you, though. Here's a PR we got automatically created the other day: -uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3 +uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3 and this PR gets run with privileges since it's from a user with write permissions.
- xign 2y ago
  I don't think you should ever allow dependabot to make direct commits to the repository. The only sane setting (IMO) is that dependabot should just make PRs, and a human needs to verify that and hit merge. My personal opinion is for any serious repositories, allowing a robot to have commit access is often a bad time and ticking time bomb (security-wise). Now, of course, if there are literally hundreds of dependencies to update every week, then a human isn't really going to go through each and make sure they look good, so that person just becomes a rubber-stamper, which doesn't help the situation. At that point the team should probably seriously evaluate if their tech stack is just utterly broken if they have that many dependencies.
  - deleted 2y ago
    [deleted]
  - matsemann 2y ago
    Even if you don't automerge, the bots will often have elevated rights (it needs to be able to see your private repository, for instance), so it making a PR will run your build jobs, possibly with the updated version, and just by doing that expose your secrets even without committing to main.
- 0rzech 2y ago
  From security standpoint, automating GitHub action hash updates defeats the purpose of pinning them in the first place.

by 0rzech 2y ago

brokenpip3 2y ago

>It's a bit more manual work after this incident, I started pinning all my github workflows with hashes, like other folks here I guess :D But I quickly got tired of doing it manually so I put together this [0] quick and dirty script to handle it for me. It just updates all workflow files in a repo and can be also used as a pre-commit hook to catch any unpinned steps in the future. It’s nothing fancy (leveraging ls-remote), but it’s saved me some time, so I figured I’d share in case it helps someone else :) [0] https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov-file#github-actions-hash https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov...

0rzech 2y ago
> github action dependency with the hash of the specific tag and a human readable tag that dependabot will keep/update in the future [1] Allowing bots to do that is going to make you vulnerable to such attacks anyway. [1] https://github.com/brokenpip3/pre-commit-hooks/blob/f01df657bd43b5043994cf981b216374c15f6ef3/README.md#github-actions-hash https://github.com/brokenpip3/pre-commit-hooks/blob/f01df657...

matsemann 2y ago

You would still be exposed if you had renovate or dependabot make a PR where they update the hash for you, though. Here's a PR we got automatically created the other day: -uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3 +uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3 and this PR gets run with privileges since it's from a user with write permissions.

xign 2y ago
I don't think you should ever allow dependabot to make direct commits to the repository. The only sane setting (IMO) is that dependabot should just make PRs, and a human needs to verify that and hit merge. My personal opinion is for any serious repositories, allowing a robot to have commit access is often a bad time and ticking time bomb (security-wise). Now, of course, if there are literally hundreds of dependencies to update every week, then a human isn't really going to go through each and make sure they look good, so that person just becomes a rubber-stamper, which doesn't help the situation. At that point the team should probably seriously evaluate if their tech stack is just utterly broken if they have that many dependencies.
- deleted 2y ago
  [deleted]
- matsemann 2y ago
  Even if you don't automerge, the bots will often have elevated rights (it needs to be able to see your private repository, for instance), so it making a PR will run your build jobs, possibly with the updated version, and just by doing that expose your secrets even without committing to main.
0rzech 2y ago
From security standpoint, automating GitHub action hash updates defeats the purpose of pinning them in the first place.