GitHub kills search after passwords, SSH keys exposed | Hacker News Reader

GitHub kills search after passwords, SSH keys exposed

scmagazine.com.au

23 pointsmaskofsanity15 comments

This article is just wrong, we are in no way removing code search. Basically, we got more traffic than we anticipated and our elastic search clusters fell over.

We have developers currently working late into the night fixing it, any updates will be posted here https://status.github.com/

Is it GitHub's responsibility to protect their users from their own stupidity?

I'd argue it's not, but the issue creates such bad PR that it'd be prudent for them to add some sort of check. However, it should probably be a bit more nuanced than killing search :)

It's not stupidity. It's statistics. There' s 1 million plus in projects, 2 million plus in repositories, and 1 million plus in users using the product over a stretch of nearly 5 years.

If those searches had uncovered no passwords whatsoever - now that would be surprising. This is just what would be expected - just by sheer chance. And yes - it is Github's responsibility to protect its users from their own stupidity.

Github's sole value is in its community - any of the technical issues that they have to deal with are commodity and have already been dealt with before else where. Github's net worth is in its community good will and path dependence.

Killing search for now is the right decision to keep the gravy train running.

Well think of it this way. If a high profile hack occurs because of this, even though we all know it's the fault of the committing developers, what do you think the tech headlines are going to be:

"Poor software engineering practices lead to exposed vulnerabilities again"

Or: "Hackers use Github to launch destructive attack on tech companies' databases"?

That kind of headline would make it especially hard for code teams to convince corporate IT to let them have a github account, even for private repos.

Github did the most sensible thing...it's too hard to come up with a provably effective filter that prevents the compromise of inadvertently exposed data.

I'm guessing it's a temporary attempt to give users some time to clean up the mess they've made for themselves.

From a quick check of their homepage and blog, I found no mention of the issue. If they were indeed giving the users a "grace period," wouldn't they want to publicize that?

Still putting together the approach to take?

It also turned up a pedophile from a .zsh_history file:

http://www.reddit.com/r/netsec/comments/177g0c/the_new_githu...

Edit: Looks like GitHub staff disabled the repository in question. Covering for pedophiles, really? Please tell me it isn't what it looks like. Although the guy was already reported.

Edit 2: Looks like this whole thread has been nuked off of HN. WTF?

It says here that it's a technical problem. https://status.github.com/

I kind of hope so because the new search was a lot better than the old search.

I'd hate to think a small group of people ruined it for everybody by uploading files they shouldn't have.

> 2:15 UTC Search remains unavailable. The cluster is > recovering slowly and we continue to monitor its progress. > Well provide further updates as they become available.

Recovering from what? Was it DoS'd?

Maybe it's shut down for customer security and privacy reasons and they knew it would be a huge news story if people found that out why, so they gave another reason.

Google search works just as well ... site:github.com id_rsa

I just clicked through a few on Google.. Obviously it's up to users to protect themselves:

https://github.com/Cerberus98/ssh_keys/blob/master/id_rsa

Search still exists but apparently just for repositories and users. If you click on Code it will tell you that it couldn't find any results. Looks like a temporary bandage.

Reply on news.ycombinator.com