61–70 of 105 posts
Earlier quoted context omitted.
We just built our own build scripts (in make(1) like god intended) and wrap jenkins around that. Pretty hard to go wrong with tech that's been tested for the last 35 years
With due respect, God probably had little to do with make.
Just a thought, but it would be interesting if there was a DDoS attack on the github status page. Then what would we do?
Earlier quoted context omitted.
This happens to our team too. Does anyone else find it ironic that Git is a distributed version control system, yet we rushed to centralize it and base our entire workflow around GitHub?
Github is just a node. IF Github dies , people still have the full repos on their computers.That's not always the case with SVN... And most people are too lazy/dont have resources to set up a git server anyway.
Nobody denies your blobs are safe and available elsewhere when Github goes down.
It's the infrastructure around those blobs that makes Github so popular. It's your issues and pull requests, your wiki, your connection to Travis-CI that are gone when Github goes down.
That is why people get angry when it goes down.
Why is this happening to them almost every day? Is someone jealous? Proving a point? If so, what point? Surely by now, GitHub must know who's responsible and putting more in place to mitigate as much as possible before this happens. Right?
Everyday? The last attack was August 4th. https://status.github.com/messages
Earlier quoted context omitted.
The so what is that the majority of people on HN are developers and the majority of them use Github either personally or with their teams. So a major outage is costing potentially millions of dollars in potentially lost developer time. If you calculate an average hourly of just $50 and a developer loses 20 minutes. Then that outage costs $17 x the number of affected developers. That's a pretty big loss. I'm reading H…
You can't pull code from another node, i.e another developer? Git is distributed, if you want centralised source control use Perforce or SVN or something.
Can someone with experience mitigating an attack like this describe how it's done? A known set of hosts/address spaces is fine, but it's the "distributed" part I don't understand how to deal with.
1. All of this requires that you have more bandwidth than the attacker.
2. ACL drop everything but the ports/protocols you use on your frontend IP. For github.com that would be TCP 80 and 443. (ACLs are cheap, can be done at wire-rate on any capable edge router, so they're a good "first step." In this case it would have the bonus of dropping DNS amplification attacks which are increasingly common.)
3. If it's a TCP SYN flood (probably from spoofed IPs) enable SYN cookies. (Of course now the bottleneck is their load balancer.)
4. If it's an L7 attack, they'll need to identify patterns in the requests to identify and drop the traffic. For example, the attacker may be requesting a single URL only. If it's an L7 attack on a TCP service, they can also automatically add a drop rule for that source address, because at this point the client IP will have been validated (via the SYN challenge).
They may also be able to identify certain patterns in the traffic that can be ACL'd at the edge. For example, IP TTL being identical.
git daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/
This is getting really problematic. It stops our whole team every time. Anybody has experience with Gitlab and Gitlab CI? How's the flow compared to Github, especially for pull requests, commenting and collaboration?
Earlier quoted context omitted.
Github is just a node. IF Github dies , people still have the full repos on their computers.That's not always the case with SVN... And most people are too lazy/dont have resources to set up a git server anyway.
Most teams that work on GitHub have none of their own workflow or infrastructure for sharing code when GH goes down. You can probably blame those teams for that more than GitHub but people do seem to have bought into the idea that we can just jam everything up to GitHub and get it back later.
The Heroku/AWS outages a few years back had far more of an impact, yet Heroku still (to my knowledge) relies exclusively on AWS-East, because presumably the risk-profile doesn't exceed the threshold to justify the expenditures required to mitigate the risk.
I just wish the attackers would be considerate enough to share the schedule for these attacks ahead of time, so I can plan a longer lunch. The rudeness of these attackers is unparalleled. I'm inclined to write them a strongly worded letter suggesting same.