3 ms·

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I used GitHub actions when building a fin services app, so I absolutely used the hash to specify Action dependencies. I agree that this should be the default, or even the required, way to pull in Action dependencies, but saying "almost no one does" is a pretty lame excuse when talking about your own risk. What other people do has no bearing on your options here. Pin to hashes when pulling in Actions - it's much, much safer

smpretzer 2y ago
I have been using renovate, which automatically pins, and updates, hashes. So I can stay lazy, and only review the new hash when a renovate PR gets opened: https://docs.renovatebot.com/modules/manager/github-actions/#digest-pinning-and-updating https://docs.renovatebot.com/modules/manager/github-actions/...
dijit 2y ago
I think the HN community at large had a bit of a learning experience a couple of days ago. "Defaults matter" is a common phrase, but equally true is: "the pattern everyone recommends including example documentation matters". It is fair to criticise the usage of GH Actions, just like it's fair to criticise common usage patterns of MySQL that eat your data - even if smarter individuals (who learn from deep understanding, or from being burned) can effectively make correct decisions, since the population of users are so affected and have to learn the hard way or be educated.
- deleted 2y ago
  [deleted]
- hn_throwaway_99 2y ago
  I wholeheartedly agree, and perhaps it was just how I was interpreting the author's statement in the article. If it's saying that the "default" way of using GitHub Actions is dangerous and leads to subtle security footguns, I completely agree. But if you know the proper way to use and secure Actions, saying "everyone else does it a bad way" is irrelevant to your security posture.
progbits 2y ago
But there is no transitive locking like package manager lockfiles. So if I depend on good/foo@hash, they depend on bad/hacked@v1 and V1 gets moved to malicious version I get screwed. This is for composite actions. For JS actions what if they don't lock dependencies but pull whatever newest package at action setup time? Same issue. Would have to transitively fork everything and pin it myself, and then keep it updated.
gazereth 2y ago
Pinning dependencies is trading one problem for another. Yes, your builds will work as expected for a stretch of time, but that period will come to an end, eventually. Then one day you will be forced to update those pinned dependencies and you might find yourself having to upgrade through several major versions, with breaking changes and knock-on effects to the rest of your pipelines. Allowing rolling updates to dependencies helps keep these maintenance tasks small and manageable across the lifetime of the software.
- baq 2y ago
  Not pinning dependencies is an existential risk to the business. Yes it’s a tradeoff, you must assign a probability of any dependency being hijacked in your timeframe yourself, but it is not zero.
  - tasuki 2y ago
    I don't think others were necessarily talking about "business". Though, yes, I prefer pinning dependencies for my personal projects. I don't see why things should break when I explicitly keep them the same.
- StrLght 2y ago
  You don’t have to update them manually. Renovate supports pinned GitHub Actions dependencies [1]. Unfortunately, I don’t use Dependabot so can’t say whether it does the same. Just make sure you don’t leak secrets to your PRs. Also I usually review changes in updated actions before merging them. It doesn’t take that much time, so far I’ve been perfectly fine with doing that. [1]: https://docs.renovatebot.com/modules/manager/github-actions/#digest-pinning-and-updating https://docs.renovatebot.com/modules/manager/github-actions/...
  - chuckadams 2y ago
    Dependabot does support pinned hashes, even adds the comment after them with the tag. Dependabot fatigue is a thing though, and blindly mashing "merge" doesn't do much for your security, but at least there's some delay between a compromise and your workflow being updated to include it.

smpretzer 2y ago

I have been using renovate, which automatically pins, and updates, hashes. So I can stay lazy, and only review the new hash when a renovate PR gets opened: https://docs.renovatebot.com/modules/manager/github-actions/#digest-pinning-and-updating https://docs.renovatebot.com/modules/manager/github-actions/...

dijit 2y ago

I think the HN community at large had a bit of a learning experience a couple of days ago. "Defaults matter" is a common phrase, but equally true is: "the pattern everyone recommends including example documentation matters". It is fair to criticise the usage of GH Actions, just like it's fair to criticise common usage patterns of MySQL that eat your data - even if smarter individuals (who learn from deep understanding, or from being burned) can effectively make correct decisions, since the population of users are so affected and have to learn the hard way or be educated.

deleted 2y ago
[deleted]
hn_throwaway_99 2y ago
I wholeheartedly agree, and perhaps it was just how I was interpreting the author's statement in the article. If it's saying that the "default" way of using GitHub Actions is dangerous and leads to subtle security footguns, I completely agree. But if you know the proper way to use and secure Actions, saying "everyone else does it a bad way" is irrelevant to your security posture.

progbits 2y ago

But there is no transitive locking like package manager lockfiles. So if I depend on good/foo@hash, they depend on bad/hacked@v1 and V1 gets moved to malicious version I get screwed. This is for composite actions. For JS actions what if they don't lock dependencies but pull whatever newest package at action setup time? Same issue. Would have to transitively fork everything and pin it myself, and then keep it updated.

gazereth 2y ago

Pinning dependencies is trading one problem for another. Yes, your builds will work as expected for a stretch of time, but that period will come to an end, eventually. Then one day you will be forced to update those pinned dependencies and you might find yourself having to upgrade through several major versions, with breaking changes and knock-on effects to the rest of your pipelines. Allowing rolling updates to dependencies helps keep these maintenance tasks small and manageable across the lifetime of the software.

baq 2y ago
Not pinning dependencies is an existential risk to the business. Yes it’s a tradeoff, you must assign a probability of any dependency being hijacked in your timeframe yourself, but it is not zero.
- tasuki 2y ago
  I don't think others were necessarily talking about "business". Though, yes, I prefer pinning dependencies for my personal projects. I don't see why things should break when I explicitly keep them the same.
StrLght 2y ago
You don’t have to update them manually. Renovate supports pinned GitHub Actions dependencies [1]. Unfortunately, I don’t use Dependabot so can’t say whether it does the same. Just make sure you don’t leak secrets to your PRs. Also I usually review changes in updated actions before merging them. It doesn’t take that much time, so far I’ve been perfectly fine with doing that. [1]: https://docs.renovatebot.com/modules/manager/github-actions/#digest-pinning-and-updating https://docs.renovatebot.com/modules/manager/github-actions/...
- chuckadams 2y ago
  Dependabot does support pinned hashes, even adds the comment after them with the tag. Dependabot fatigue is a thing though, and blindly mashing "merge" doesn't do much for your security, but at least there's some delay between a compromise and your workflow being updated to include it.