5 ms·

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'

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?

chungy 3y ago
CI systems shouldn't have the ability to make network requests at all, honestly.
- sam_lowry_ 3y ago
  If all CI systems of the world went down, it would have cooled Earth by 0.001°C.
- TrickyRick 3y ago
  How would you suggest they install dependencies then?
  - dzaima 3y ago
    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)
myhf 3y ago
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?
- MattIPv4 3y ago
  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.
  - dzaima 3y ago
    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.
tremon 3y ago
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.
- belltaco 3y ago
  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?
  - tremon 3y ago
    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-communications https://www.fcc.gov/enforcement/areas/unwanted-communication... Yes, phone companies definitely can be liable for bulk targeting by their users.
    - belltaco 3y ago
      > 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.
thepostman0 3y ago
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.

chungy 3y ago

CI systems shouldn't have the ability to make network requests at all, honestly.

sam_lowry_ 3y ago
If all CI systems of the world went down, it would have cooled Earth by 0.001°C.
TrickyRick 3y ago
How would you suggest they install dependencies then?
- dzaima 3y ago
  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)

myhf 3y ago

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?

MattIPv4 3y ago
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.
- dzaima 3y ago
  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.

tremon 3y ago

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.

belltaco 3y ago
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?
- tremon 3y ago
  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-communications https://www.fcc.gov/enforcement/areas/unwanted-communication... Yes, phone companies definitely can be liable for bulk targeting by their users.
  - belltaco 3y ago
    > 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.

thepostman0 3y ago

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.