Hacker News new | ask | show | jobs
by MattIPv4 1089 days ago
Why is GitHub the one under fire here? Users on GitHub are using GitHub Actions to build CI pipelines that build stuff, and happen to be pulling from GMP. That's not GitHub's problem that users are using their product in a legitimate manner, it seems to me it is GMP's problem that they can't handle traffic for artifacts from CI systems? It is noted the requests are identical, so would a modicum of caching in front of their origin not make this problem go away completely?
4 comments

CI systems shouldn't have the ability to make network requests at all, honestly.
If all CI systems of the world went down, it would have cooled Earth by 0.001°C.
How would you suggest they install dependencies then?
At the very least, that's an issue that GMP or other projects shouldn't have to worry about. There are many options - you could manually cache things somewhere or pack in the dependencies in the repo. Or, maybe, in a world that wasn't completely set on wasting all resources possible, there just wouldn't be pointless automatic builds on forks, and those builds wouldn't need to re-download the world and could instead just incrementally update. (yes, there are nice consequences of doing fresh builds always, but there are also bad ones as can be seen, and unfortunately the downsides aren't seen by the initiator)
Why should this host (and presumably every similar host) take on the burden of this extra complexity?

Would a modicum of caching in GitHub Actions libraries not make this problem go away for all hosts in this category?

That's fair, I would agree that caching at either end would fix this. It just strikes me as odd that GitHub, the middle-man that's just providing CI runners, is the one under fire.
What GitHub is effectively doing is providing free DDoS hardware and lots of it, as far as the receiving end is concerned. I don't think GitHub should particularly be "under fire" for this, but it's still very not nice to provide a service that, under legitimate use (never mind illegitimate use!), can make unreasonable amounts of traffic to arbitrary sites.

I think a quite reasonable expectation from GitHub would be to have an all-of-GitHub-wide rate limit that CI can use for requests to any given site, and have jobs fail/delay if GitHub has exceeded that, and expect sites to explicitly opt in if they're fine with more than that rate. Would of course very much suck for GitHub CI users that want to pull from sites not opted in, but at least GitHub would stop offering free DDoS services.

For the same reason that ISPs tend to come under fire when their customers are using MTAs to deliver large volumes of e-mails to non-consenting recipients.

Are you saying it's not an ISP's problem that spammers are using their product in a legitimate manner, but instead it's up to the recipients to build their own spam fighting resources? Yes, that turned out wonderfully.

Is it the phone companies' fault that people make death threats over the phone? Do we say 'Phone company makes death threats' when that happens like the title is saying about GitHub?
Death threats? WTF? What metaphor are you using that git clone requests are now suddenly death threats?

Anyway, I don't think your example aligns with the argument you think you're making: https://www.fcc.gov/enforcement/areas/unwanted-communication...

Yes, phone companies definitely can be liable for bulk targeting by their users.

> What metaphor are you using that git clone requests are now suddenly death threats?

The headline and title are saying GitHub DDoSed a crucial open source site, so the metaphor is definitely valid. I did not compare DDoS to death threats, I compared the fact that it is being said that GitHub DDoSed the open source site and did a thought experiment to see what happens if something similar was said about the phone companies.

If it must go to internet, a MITM SSL proxy cache out of GH would help.

The problem is within GH's network, a 90s ISP would have blocked spammy users, GH should at least operate like an ISP if random stuff can execute and reach the 'net.