4 ms·

> There’s nothing technically clever or novel here. Nothing technically novel. But evidently it was at least a somewhat novel stress test execution for GitHub’

> There’s nothing technically clever or novel here. Nothing technically novel. But evidently it was at least a somewhat novel stress test execution for GitHub’s live systems, otherwise surely it would have been dealt with sooner and messaged with less benefit of the doubt to the user. Investigating the limitations of something doesn’t have to be novel to be interesting. It’s been a while (I think), but for example there’s been plenty of praise here for Netflix’s own stress tests of its live systems. The tests are often really mundane, eg just shutting some stuff off or triggering known error conditions. It’s interesting not because the nature of the fault is novel, but because systems are complex and it’s a way to learn about their failure modes. I’m also not saying GitHub should hire them (and kinda I doubt they’d want a QA offer based on reading other blog posts on their site). Just that a hire would plausibly be similarly beneficial to a ban.

rewmie 3y ago
> Nothing technically novel. But evidently it was at least a somewhat novel stress test execution for GitHub’s live systems, otherwise surely it would have been dealt with sooner and messaged with less benefit of the doubt to the user. Not really. This is boring stuff, and odds are they never bothered with it because a) it has no impact on operations, b) the blast radius of this doesn't go beyond the attacker's own repo, c) no moron with time to kill bothered attempting this stunt until now. Probably now some low-level employee at GitHub needs to add a metric and an alarm to react to rate limits to prevent moron copycats from pulling this stunt for attention-seeking. Not smart, not clever. Just boring vandalism.
- eyelidlessness 3y ago
  [flagged]
  - rewmie 3y ago
    > Wow, you’ve really done a crack up job ruining any possibility of interesting discussion here. What interesting discussion? Any owner of any service in production is well aware of how mundane it is to have third parties poking and prodding around to assess service limits. Some people have too much idle time on their hands.
    - eyelidlessness 3y ago
      The interesting discussion is that apparently ~no one did this for well over a decade, and now we have information about where service degrades. We didn’t have that to talk about before, now we do.

rewmie 3y ago

> Nothing technically novel. But evidently it was at least a somewhat novel stress test execution for GitHub’s live systems, otherwise surely it would have been dealt with sooner and messaged with less benefit of the doubt to the user. Not really. This is boring stuff, and odds are they never bothered with it because a) it has no impact on operations, b) the blast radius of this doesn't go beyond the attacker's own repo, c) no moron with time to kill bothered attempting this stunt until now. Probably now some low-level employee at GitHub needs to add a metric and an alarm to react to rate limits to prevent moron copycats from pulling this stunt for attention-seeking. Not smart, not clever. Just boring vandalism.

eyelidlessness 3y ago
[flagged]
- rewmie 3y ago
  > Wow, you’ve really done a crack up job ruining any possibility of interesting discussion here. What interesting discussion? Any owner of any service in production is well aware of how mundane it is to have third parties poking and prodding around to assess service limits. Some people have too much idle time on their hands.
  - eyelidlessness 3y ago
    The interesting discussion is that apparently ~no one did this for well over a decade, and now we have information about where service degrades. We didn’t have that to talk about before, now we do.