6 ms·
The rampant "@V1" usage for GitHub Actions has always been so disturbing to me. Even better is the fact that GitHub does all of the work of showing you who is a
by aliasxneo 2y ago
The rampant "@V1" usage for GitHub Actions has always been so disturbing to me. Even better is the fact that GitHub does all of the work of showing you who is actually using the action! So just compromise the account and then start searching for workflows with authenticated web tokens to AWS or something similar.
It's probably already happening.
- cedws 2y agoExactly. It simply should not be allowed to do this. Nor maintain Actions without mandatory 2FA. All it takes is one account to be compromised to infect thousands of pipelines. Thousands of pipelines can be used to infect thousands of repos. Thousands of repos can be used to infect thousands of accounts... ad infinitum.
- guappa 2y ago2FA matters very little when you have never expiring tokens.
- dawnerd 2y agoAnd thanks to the likes of composer and similar devs end up making non expiring tokens to reduce annoyance. There needs to be a better system. Having to manually generate a token for tooling can be a drag.
- blueflow 2y ago2FA also matters little if the attacker has compromised your machine. They can use your 2FA-authenticated session.
- guappa 2y agoOnly once… but if they can get your forever token… that's not the same.
- GoblinSlayer 2y agoOnce is enough.
- OptionOfT 2y agoGitHub specifically recommended that you have a v1, v1.x and v1.x.x When you go from v1.5.3 to v1.5.4 you make v1.5 and v1 point to v1.5.4
- BHSPitMonkey 2y agoThe point is that any of those tags can be replaced maliciously, after the fact.
- mroche 2y agoIf tags are the way people want to work, then there needs to be a new repo class for actions which explicitly removes the ability to delete or force push tags across all branches. And enforced 2FA. Using a commit hash is the second most secure option. The first (in my eyes) is vendoring the actions you want to use in your user/org's namespace. Maintaining when/if to sync or backport upstream modifications can protect against these kinds of attacks. However, this does depend on the repo being vetted ahead of time, before being vendored.
- robertlagrant 2y agoSorry I followed up to this point - how can this be done?
- GauntletWizard 2y agoFrom the GitHub UI, very simply. Go to a repo you administer, in the /tags page, and each tag has a ... Drop-down menu with a delete option. Then upload a new tag by that name. Tags are not automatically updated from remotes on pull (they are automatically created locally if it's a new tag). This doesn't mean that the remote can't change what the tag points to, only that it's easy to spot. Edit: and to be clear, for many years after release, this was the recommendation from the Visual Source Safe team (Yes, that team developed GitHub Actions) for managing your actions. Tell people to use "v1", then delete the tag update it each time.
- 2y ago
- Twirrim 2y agoNot that long ago Facebook was accidentally leaking information through their self hosted runners, through a very common mistake people make. https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ https://johnstawinski.com/2024/01/11/playing-with-fire-how-w... That's the second time for PyTorch, to the best of my knowledge. I know someone who found that (or something very much like it) back in 2022 and reported it, as I had to help him escalate through a relevant security contact I had at Meta.