Slashdot Mirror
Github Under JS-Based "Greatfire" DDoS Attack, Allegedly From Chinese Government
An anonymous reader writes: During the past two days, popular code hosting site GitHub has been under a DDoS attack, which has led to intermittent service interruptions. As blogger Anthr@X reports from traceroute lists, the attack originated from MITM-modified JavaScript files for the Chinese company Baidu's user tracking code, changing the unencrypted content as it passed through the great firewall of China to request the URLs github.com/greatfire/ and github.com/cn-nytimes/. The Chinese government's dislike of widespread VPN usage may have caused it to arrange the attack, where only people accessing Baidu's services from outside the firewall would contribute to the DDoS. This wouldn't have been the first time China arranged this kind of "protest."
For the purported great and ancient wisdom of 5000-year-old Chinese civilization, they have pretty lousy leaders.
The West has leaders with minds like children too, but at least we can laugh at them, and eventually get rid of them. Must suck to be Chinese with these idiots in charge...
knock them off the web for 12 hours, open it up... if they continue, block 'em again...
if this is supposed to be a new economy, how come they still want my old fashioned money?
You can't compensate your evident lack of technical understanding with being condescending. Those are two different contexts for the word 'decentralized' that you are mixing up.
This is where socialism leads: Authoritarianism.
If our country weren't run by lawyers, we'd do what Russia and China do which is allow victims like GitHub to retaliate. Would be hilarious if GitHub contracted a few black hats to penetrate China's academic/military networks and give them a taste of the Wikileaks treatment.
Maybe the strategy is to publicly expose what the Chinese government goon squad are doing. Then quietly pull them aside, and tell them that they're losing face.
I have a coworker who advocates GitHub as the solution to all of our needs. He wants us to store all of our production code there. I asked him if he had a plan for backing up the GitHub repo, and his answer was along the lines of, 'someone will have the latest version on their PC, so we don't need a backup.' I asked him how we would work in times of limited GitHub availabilty. What if it goes down? What if it gets hit with DDOS? 'Oh, they're a big company, that won't happen.'
I have no fundamental problem with GitHub. But if a software shop uses it as their sole repo for mission-critical code, I think they're crazy.
Or:
3) Current leadership is incompetent and lacks the will to do something about it.
I vote 3.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
To fight back they have changed those projects to be
alert("WARNING: malicious javascript detected on this domain")
So the user sees a message =)
The modding here is atrocious.
The GP is right, and you are wrong.
There is only one form of decentralization involved here.
Even if git users have their own copies of a repo, it is not trivial to share changes among more than a couple of users, especially if they are on distinct networks with firewalls and other hindrances.
That is why GitHub is used.
GitHub negates the decentralization of git in order to make it practical for real world use.
GitHub being down may not be a problem for your rinky-dink one-man JavaScript library project that nobody uses.
But for real projects with distributed teams consisting of numerous people the decentralization of git is a big problem.
GitHub is the only practical solution to the problems of decentralization.
When GitHub is down, the entire team suffers from an inability to work.
If they resort to pushing and pulling from one another's repos, then they will waste more time doing that then they will actually doing real work!
Some teams will just set up a temporary git repo when GitHub is down.
But that is still an example of them centralizing, because decentralized version control is an impractical idea.
Git only works well in the real world when it is centralized.
GitHub and its popularity and necessity prove this to be true.
The greatfire guys always post something about ways to bypass the wall and changes in the wall's behavior.
But for real projects with distributed teams consisting of numerous people the decentralization of git is a big problem.
Not really. Any real project with a reasonably sized team will have their own servers.
You really don't understand what decentralized version control is, do you?
The whole point isn't to avoid any centralization at all, it's that you're not utterly reliant on it. It's somewhat similar to the argument between a big server and thin clients (where nearly all computation is on the server) and "thick clients" (PCs) and less-capable servers (for sharing files, etc.). With a big server, if that server goes down or the connection to it goes down, you're screwed, and can't do anything. With today's more common thick-client paradigm, if your office file server goes down, you can't easily share files with your coworkers and other things are inaccessible, but you can still get some work done using whatever local copies you have.
This is what DVCS is all about. With Git, you have a full copy of the repo just by virtue of having "checked out" a copy. You can still get some work done without access to the central server, whether it's down or your WiFi connection is down or your VPN is down. You can't do everything obviously, nor will you ever be able to, but that's not the point. And, in a worst-case scenario, if the central server just disappears one day without accessible backups, everyone with a copy checked out has the full repository, so it's possible to rebuild easily.
Fix is pretty obvious.
There are two URLs being hit.
Step 1: Put a reverse proxy cache which serves static pages directly out of RAM from a kernel module in front of GitHuB. If there's nothing like this for Linux, there is for FreeBSD, and it's pretty trivial to set up.
Step 2: At the first URL, serve pro Free Tibet information. At the second URL, serve pro Falun Gong information.
Step 3: Wait for someone in China in charge of the attack to call it off in fear for their life from the government for serving this illegal in China content to everyone in China going to one of the affected web sites that has the javascript injected.
Step 4: (optional) Laugh your ass off as they are sent to a reeducation camp.
You can still get some work done without access to the central server, whether it's down or your WiFi connection is down or your VPN is down.
Same is true for subversion. In both cases you can develop and test your code and review your changes against what was last seen original copy. All the rest (preparing commits early so you can push them faster when connectivity is restored) is just a detail.
Github changes git into centralized subversion-like system, just with a lot better branching/merging mechanism (which is a HUGE difference, don't get me wrong) - but if it is down, your cooperation workflow is going to suffer badly.
It does not matter who hosts and manages the centralized server(s).
Maybe it is GitHub.
Maybe it is the development team itself.
The important point is that it is centralized.
Centralization is the only way to make git useful for projects with more than one developer.
If Korporate AmeriKa hadn't (along with their subsidiary, the US gov't) offshored all the jobs, technology and investment to China, they wouldn't have been capable of doing this. We now stand at a disadvantage, thanks to the banksters!
The modding here is atrocious.
The GP is right, and you are wrong.
There is only one form of decentralization involved here.
Even if git users have their own copies of a repo, it is not trivial to share changes among more than a couple of users, especially if they are on distinct networks with firewalls and other hindrances.
That is why GitHub is used.
All true.
GitHub negates the decentralization of git in order to make it practical for real world use.
GitHub being down may not be a problem for your rinky-dink one-man JavaScript library project that nobody uses.
But for real projects with distributed teams consisting of numerous people the decentralization of git is a big problem.
GitHub is the only practical solution to the problems of decentralization.
This can actually be mitigated by several different means:
It's just a matter of deciding where the "master" copy resides and keeping them all (hopefully automatically) in sync.
Now, this can be managed with tools like Subversion too, using replication, but it's no where near as nicely done as it is in git.
However, if you don't take the time to do the replication between several services then yes, you are risking this kind of situation.
Or, you could take advantage of this kind of replication by using the DVCS nature of git to your advantage.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
<span>Github Under JS-Based "Greatfire" DDoS Attack, Allegedly From {{enemyOfTheDay}}</span>
There's a world of difference between having an agreed-upon repository of record, and having a centralized system. A big part of the difference is that setting up a pro-tem repository of record can be done trivially from any up-to-date repository.
GitHub is convenient. It's not necessary.
Same is true for subversion. In both cases you can develop and test your code and review your changes against what was last seen original copy
Subversion has gotten better recently... but in the past nearly every command required a round-trip to the central server. Like I say, that has recently changed for a few (like 'svn stat') but there are still MANY that require a live link to the central server.
Contrast this with Git where the _only_ time you need to access a server is for sharing.
When GitHub is down it only takes one command to push your whole repo to BitBucket so you can keep working with peers. Sure, you don't have access to any *data* (wiki, issues, etc) that you had on GitHub... but the most important thing (the code) is VERY mobile.
It does seem like it'd be really nice if we had some easy way of replicating wikis and bugtrackers, so we could move those around as needed, like we do with Git.
Well... on GitHub the wiki _is_ actually stored in a Git repo... and all of the pages are simply Markdown. They are VERY easy to move to many other systems (or even to view locally).
GitHub even publishes an open source version of its wiki renderer to make it even easier: https://github.com/gollum/goll...
NOW: The bugtracker stuff is a little more difficult. You can use the GitHub API to pull out all of the info easily enough and store it locally... but you have to do some sort of transformation to get it into a new format if you're trying to move to a different service.
Personally, I've done this the other way around. We went from using Trac on our own servers to using GitHub. I wrote scripts to take all of our Tickets from Trac and upload them to GitHub as Issues using the GitHub API. It was a pain but not impossible....
Same is true for subversion. In both cases you can develop and test your code and review your changes against what was last seen original copy.
It's admittedly been a while since I last used SVN, but it was not at all like Git; it was entirely centralized and required server access to do almost anything. Not every developer has a full copy of the repo, as they do with Git. It was pretty slow when I used it too (though nothing like ClearCase).
With Git, you can check in changes, create branches, etc. all you want without needing any network access at all. You only need network access and server access when you want to share those changes with others. This just isn't possible in a centralized version control system.
Github changes git into centralized subversion-like system
No, it doesn't. It facilitates sharing between developers, and that's all. This is not like a centralized VCS, where you need server access to actually do version-control.
but if it is down, your cooperation workflow is going to suffer badly.
No, not really. The whole point to the GitHub (or similar) server is to provide a single point to facilitate sharing. Without it, you'll need to do pushes and pulls directly between developers' machines, which obviously is inefficient, but is doable. However, it's also trivial to switch to a new central server at any time: just stop using the old one, clone the latest version of the repo (which whoever last pushed to GitHub would have) to the new server, have everyone point to the new server, and you're done. That's something you can't easily do with a centralized VCS.
Actually you can also distribute the central servers of git.
I personally have some projects located on two servers and some on three.
You can push and pull changes on multiple servers and let git figure out the mess.
With Git, you have a full copy of the repo just by virtue of having "checked out" a copy.
Quick nitpick: that would be a clone, not a checkout.
For the non-git-users among us:
git clone: copy that repository to my local file-system. (All branches are copied across. This is normally over ssh or https.)
git checkout: give me the specified branch. (Doesn't require use of the network.)
git fetch: update the local store of the repository to reflect the current state of the repository on the server.
As opposed to what? Subversion would be completely unusable in this situation, at least git users can push and pull from each other peer to peer, which you would only do if you REALLY need it, because it is kinda of a pain in the ass compared to push/pulling to origin. Plus you CAN carry on your own work keeping a normal commit history as long as you don't want to share it with anyone until the servers come back online.
Really, it is "the greatest thing ever (for source control)".
# git remote add newupstream git://new.server/my-project
# git push master newupstream
Aaaaand, done.
You're not going to do that with Subversion anytime soon. Sorry - I like SVN. But to claim that having a central repository is anything like *requiring* a central repository is just missing the point.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
GitHub negates the decentralization of git in order to make it practical for real world use.
Negates? No - it just provides a single location through with to share code. You're confusing "using a central repository" with "requiring a central repository." It is just above trivial for any git project to switch to a new "central" server through with to share code.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
So basically Baidus search results is being hijacked to run a JS script in the client computers. Unlike a normal DDOS the client computer hasn't yet been compromised.
Baidu’s traffic hijacked to DDoS GitHub.com
If it's vigilantism for GitHub to conduct a private retaliation against the Chinese government, then one could call what the Chinese did an act of war. Hey, if we're tossing around emotionally loaded terms without regard for the context, why stop with just calling that hypothetical action by GitHub an act of vigilantism.
With Git, you have a full copy of the repo just by virtue of having "checked out" a copy. You can still get some work done without access to the central server
sure, as long as you aren't collaborating on anything, or if you are, you have a mirror. my guess is that most github users don't create mirrors.
GitHub is the only practical solution to the problems of decentralization.
did you mean git? or github? you don't need github to setup a git remote.
Why not setup every computer in the U.S. in like a beowolf cluster and mass DDos China. Shut the whole country down. No loss there.... Might help generate new manufacturing jobs in the U.S...
The Truth is a Virus!!!
Same is true for subversion. In both cases you can develop and test your code and review your changes against what was last seen original copy. All the rest (preparing commits early so you can push them faster when connectivity is restored) is just a detail.
Depends on how you use commits and what you think they are for. As they say, the devil is in the detail... in this case, the area you've marked out probably contains enough room for the entirety of hell ;-)
The key advantage of git is that if the central server goes down, I can spin up a complete copy (using git itself, emails, or an existing open source git server) and restore a large portion of collaboration. Subversion can't do that.
When the big changeover from SVN being the #1 VCS to git taking the crown happened, SVN did not have those features. You couldn't check in changes without talking to the server. If the server was down, you'd have to wait and check in all your changes at once. That was one of the big features of git that had people excited; they could still do local checkins. The only thing they were missing when the server was down was sharing the code and handling any conflicting changes. But actually checking the changes in doesn't get messed up.
Sure, after "everybody" switched, then SVN finally added the needed parts of de-centralization. I actually enjoyed using svn more than git, but I sure don't regret switching. If nobody had switched, we'd still be without modern features...