Re:We Executed a Critical Supply Chain Attack on PyTorch
by KptMarchewa on Sunday January 14, 2024 @04:50PM
(#38994774)
GH actions are free on public repos.
Re:We Executed a Critical Supply Chain Attack on PyTorch
by Groxx on Sunday January 14, 2024 @10:52PM
(#38997287)
Until someone tries to mine Bitcoin in yours, yeah
Re:We Executed a Critical Supply Chain Attack on PyTorch
by trevyn on Monday January 15, 2024 @04:24AM
(#38998856)
Do you have a case study?
My prior is that GitHub is pretty competent in understanding malicious PRs to open source repos, and wouldn’t penalize the repo owner without other evidence of wrongdoing.
Re:We Executed a Critical Supply Chain Attack on PyTorch
by guappa on Monday January 15, 2024 @01:25AM
(#38997953)
They are so difficult. I wanted to stop random people to run code on my repository… I don't have any secrets or write access or anything to exploit. Just to avoid burning quota.
The issue is that now the pull requests don't get tested at all. I have to manually, locally, get all the commits, make a branch on the main repository with them, and then the actions run.
Re:We Executed a Critical Supply Chain Attack on PyTorch
by Groxx on Monday January 15, 2024 @02:01AM
(#38998143)
That just plain sounds Bad™, yeah. In the buildkite setup I interact with, I can at least just hit the "continue" button on the paused pipeline, regardless of any other GitHub state... which feels like table stakes to me.
Re:We Executed a Critical Supply Chain Attack on PyTorch
by growse on Thursday January 18, 2024 @08:38AM
(#39041526)
One approach might be to review manually, then label the pr and trigger the pr based off the label being added.
Challenge there is that if the pr changes, it's a bit clunky to retrigger the CI (you have to remove, then re-add).
I guess you could also do this with comments - can you trigger a workflow based on a specific comment being added from a specific user?
When there are no side effects and no in-container secrets and the hosting is free or reasonably limited to prevent abusers, ideally yes.
Outside that, heck no, that'd be crazy. You're allowing randos to run arbitrary code on your budget. Locking it down until it's reviewed is like step 1, they can validate locally until then.