More correct title would be "GitHub stopped abuse after 22M commits".
There is absolutely nothing wrong with GH stopping that and it's very wrong to insinuate otherwise like OP is doing.
Wouldn't be surprised if GH would permaban him.
There is absolutely nothing wrong with GH stopping that and it's very wrong to insinuate otherwise like OP is doing.
Wouldn't be surprised if GH would permaban him.
I don’t want to quibble with the term “abuse”, because I think in this scenario it depends on whether intent is a factor and whether we should trust their stated intent. But depending on how you look at it, GitHub would be just as likely to benefit from hiring the author as they would from banning.
It's a wordplay to call that anything else than abuse.
For what purpose?
Creating an infinite loop that updates a file and commits it is hardly worthy of a job offer.
It's entirely possible that such a load test has been considered, but deemed non-realistic so not prioritised for some time. If I were running the QA team I'd be annoyed if time were spent on abusive destructive testing than realistic testing that real-world users may experience, especially because load testing like this would have to be on an identical environment to PROD so rather expensive.
It reminds me of that old QA joke:
A QA engineer walks into a bar and orders a beer. She orders 2 beers.
She orders 0 beers.
She orders -1 beers.
She orders a lizard.
She orders a NULLPTR.
She tries to leave without paying.
Satisfied, she declares the bar ready for business. The first customer comes in an orders a beer. They finish their drink, and then ask where the bathroom is.
The bar explodes.
GitHub hasn't failed here - it continued to perform at normal levels for other users, so far as I can see, and they had an upstream process which caught the issue without the system failing. Maybe some exploratory testing had previously identified where that process should kick in, but without having an automated process since it was so unlikely to happen.
Not really. GitHub has been around for over a decade. People bother with problems that have a realistic chance of happening. If GitHub didn't bothered to rate limit commits it means it was a potential issue that didn't manifested itself for over a decade.
People tend to bother about problems that happen. Otherwise everyone would be freaking out because of killer asteroids.
To start off, based on the fact that GitHub is around for over a decade and this was the first time this sort of attention-seeking stunt was made public.
Do you have any indication this sort of stunt is relevant?
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.
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.
Everyone can drive a car. Did everyone invent Uber?
You're underrating the non-technical factors.
More than 20 years later, I still remember the enormous benefit that little bit of malice has bestowed on me and my career. And every time I’ve been on the receiving end of such an exploratory exploit since has been exponentially more appreciated.
At a previous job I was aware of a potential vulnerability, voiced it rather loudly, but had a hard time getting the attention it deserved until I recognized it happened to coincide with a really high profile business-critical bug. I only recognized it because some jerks had previously fucked with much less important stuff under my purview, and I wanted very much to understand how they did it, and learned quite a bit by wanting to know.
I used those developed instincts to unfuck what would have otherwise resulted in at least contract terminations, if not lawsuits. And the recognition allowed me to correct almost every compromised datum, which also guarded every contractee from challenges to their license status and ultimately whether they could be subject to wholly different jurisdictional context.
I’m not going to disclose the nature of the vulnerability but the way the bug presented was time deltas based on time zone configuration. Hardly a novel problem, but nearly put a whole industry into peril and or conflict. Definitely was worth the attention.
And when communicating the problem suffered, I did what any self respecting hacker would do: I exploited the damn thing myself and showed how it was done.
Arguably, it would be better if GitHub documented an explicit number of supported commits, so that one can know beforehand which usage scenarios the service is suitable for.
I don't agree. Clearly GitHub can easily handle this number of commits, and more. There was no real world limit being hit. There is no user impact or degraded performance.
This means that in practice there is absolutely no practical limit in GitHub.
Why document that? Are you planning on working on pushing more than 22 million commits into a project? And if you are, what stops you from sending an email to GitHub to clarify if it supports your extraordinary usecase?
It seems some people around here are desperate to find any flaw in the way GitHub handled this case of vandalismz and at best are grasping at straws.