×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Github Kills Search After Hundreds of Private Keys Exposed

Soulskill posted about a year ago | from the take-care-what-you-make-public dept.

Encryption 176

mask.of.sanity writes "Github has killed its search function to safeguard users who were caught out storing keys and passwords in public repositories. 'Users found that quite a large number of users who had added private keys to their repositories and then pushed the files up to GitHub. Searching on id_rsa, a file which contains the private key for SSH logins, returned over 600 results. Projects had live configuration files from cloud services such as Amazon Web Services and Azure with the encryption keys still included. Configuration and private key files are intended to be kept secret, since if it falls into wrong hands, that person can impersonate the user (or at least, the user's machine) and easily connect to that remote machine.' Search links popped up throughout Twitter pointing to stored keys, including what was reportedly account credentials for the Google Chrome source code repository. The keys can still be found using search engines, so check your repos."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

176 comments

At least... (5, Funny)

Anonymous Coward | about a year ago | (#42689973)

they've been seen by 'many eye balls'.

That's good right?

Re:At least... (1)

Anonymous Coward | about a year ago | (#42690161)

I don't know about that. I, for one, don't want my eyeballs seeing any of you guys expose your private "keys"

Re:At least... (1)

nitehawk214 (222219) | about a year ago | (#42690913)

I don't know about that. I, for one, don't want my eyeballs seeing any of you guys expose your private "keys"

Especially Goldmember's private key.

Re:At least... (1)

i_ate_god (899684) | about a year ago | (#42691263)

neither do I, but seeing the locks would be something I'd be interested in

Re:At least... (0)

Anonymous Coward | about a year ago | (#42691503)

neither do I, but seeing the locks would be something I'd be interested in

You are going to need a mirror and moderate flexibility.

Re:At least... (0)

Anonymous Coward | about a year ago | (#42690215)

they've been seen by 'many eye balls'.

That's good right?

Kerckhoff's Principle is that a cryptosystem should be secure even if every detail about its implementation is known, EXCEPT for the key.

Re:At least... (1)

Anonymous Coward | about a year ago | (#42690263)

that may have whooshed you. OP was making a joke about the whole "open source makes it more secure because more people have looked at it" idea.

Re:At least... (1)

Anonymous Coward | about a year ago | (#42690497)

The key here is that it was a horrible joke, as anyone can see.

Re:At least... (1)

Anonymous Coward | about a year ago | (#42691345)

Privately, I agree. Publicly, I feel the same.

Re:At least... (0)

Anonymous Coward | about a year ago | (#42690559)

Which, essentially, follows roughly the same principle. With the exact same exception.

This is why developers are not sysadmins (3, Insightful)

h4rr4r (612664) | about a year ago | (#42689993)

This is why developers are not sysadmins.

These kinds of repositories need to learn that and not let these folks do this sort of thing. If would be simple to use a regex to filter out the posting of these sorts of files. Maybe Devs should even be charged a couple dollars to get a decent review of these things.

Re:This is why developers are not sysadmins (5, Insightful)

Anonymous Coward | about a year ago | (#42690021)

No. This is actually completely absurd. A developer that cannot grasp the concept that private keys have to be kept private, cannot be trusted to do anything but screw up the most basic security provisions when writing code.

They should get a kick in the ass, such as three months without any sort of commit privileges, and mandatory code review for an year. THAT should be enough to make it stick, and impress on them the real gravity of their failure. Otherwise, they will just chalk it up as "an annoyance done by those uninteresting people who should learn to code before they go pestering code-gods".

Re:This is why developers are not sysadmins (4, Interesting)

h4rr4r (612664) | about a year ago | (#42690145)

Sysadmins should also know how to code. Nothing better than showing them their screwup and the solution to it.

Plus, since all sysadmins, real ones anyway, are already competent in several scripting languages it is not that hard a skill to add if all you need to do is be better than bottom of the barrel programmers.

Re:This is why developers are not sysadmins (1)

Zeromous (668365) | about a year ago | (#42690899)

I can't remember the last time a developer had a workable, secure solution to my problems.

There's a reason you hear, 'fix your own code' a lot more than 'fix your servers' in a development environment.

Re:This is why developers are not sysadmins (1)

RevDisk (740008) | about a year ago | (#42691153)

I concur. SysAdmins should know how to write a script. I certainly ask any sysadmin I hire what programming or scripting languages they know. If they don't, I assign them tasks to learn VBS and Linux shell scripts, as a start. If a sysadmin is running web servers, they need to know decent amount of HTML and PHP. Enough to see how it is interacting with the infrastructure.

They don't have to be "professional programmers". Minimum is enough to understand what's going on. Code and scripts run on logic. If a sysadmin can't work out logic problems, I don't want them touching my infrastructure.

Re:This is why developers are not sysadmins (1)

Anonymous Coward | about a year ago | (#42690369)

You are correct that the penalties for something like this should be severe, but in the meantime, the damage done by people who expose their private keys in this way is still done, and still needs to be mitigated. A basic heuristic should not be hard. When a commit comes in, look commit for .ssh directories, and if they are found, look in those directories for valid private key files. If private keys are found, reject the commit, send the developer an automated nastygram ("We stopped this, but do you realize what in the flying blue fark you could have done?!"), and trigger the penalties.

This is an imperfect solution, of course. It doesn't look anywhere but the default location for private keys. But this is the common case by such a huge margin that it should be enough: anyone who knows how to (and cares enough to) get their keys into a non-default location either knows what they're doing or deserves what they get.

Re:This is why developers are not sysadmins (1)

stewsters (1406737) | about a year ago | (#42690053)

I don't think that would be easy to implement. In git you add and commit your changed to a local repository, then push them back to github. Somehow cutting them out later would give you really cool errors. They would need to catch them on your commit locally. The real question should be why those keys were placed inside the project directory, and not somewhere like ~/.ssh/

Re:This is why developers are not sysadmins (1)

h4rr4r (612664) | about a year ago | (#42690123)

Could they not supply a .gitignore ?
Either way simple enough to have a find script run, before you make it public. Basically on every commit turn off public access, run your clean script, then turn it back on. If this causes errors, that seems better than this.

I admit at work we mostly use a combination of CVS and a 2x4 to hit developers with to avoid these issues while still having a nice simple repository.

Re:This is why developers are not sysadmins (5, Insightful)

ArsenneLupin (766289) | about a year ago | (#42690191)

In some of these instances, all of ~/.ssh/ [github.com] did actually end up in the project directory. Or maybe they used their entire home directory as the project root? Stoopid, stoopid people.

(Yes, there is also a nice ~/.ssh/config file, so that you also know which locks those key fits...)

Re:This is why developers are not sysadmins (3, Insightful)

Raumkraut (518382) | about a year ago | (#42690349)

I've seen several people comment that they have their home directory config files under version control. If you're using git for that, it's a fairly simple next step to then "backup" the repo to github.
"It's only config files; nobody would be interested in those."

Re:This is why developers are not sysadmins (1)

tzanger (1575) | about a year ago | (#42690989)

There's absolutely nothing wrong with that. My question is why they're storing their home dir on a *public* git repo...

Re:This is why developers are not sysadmins (2)

nschubach (922175) | about a year ago | (#42691081)

Duh... it's so they don't have to remember their passwords to get their configuration and RSA keys back!

Re:This is why developers are not sysadmins (1)

Fnord666 (889225) | about a year ago | (#42691459)

There's absolutely nothing wrong with that. My question is why they're storing their home dir on a *public* git repo...

Because it's only free if it's a public repository.

Re:This is why developers are not sysadmins (1)

ethan0 (746390) | about a year ago | (#42691393)

your link has only .pub files, though. I see no private keys here.

Re:This is why developers are not sysadmins (1)

robmv (855035) | about a year ago | (#42690219)

Yo can launch a filter like program from an event before the commit is saved on the remote repository, and stop with an error, this force the careless developer to amend their commits

Re:This is why developers are not sysadmins (1)

h4rr4r (612664) | about a year ago | (#42690261)

If we could pair this with some sort of clue bat strike via IP that would be best.

Re:This is why developers are not sysadmins (1)

nitehawk214 (222219) | about a year ago | (#42691227)

If we could pair this with some sort of clue bat strike via IP that would be best.

I hear a guy is working on a IP-based face-stabbing machine.

Re:This is why developers are not sysadmins (1)

petermgreen (876956) | about a year ago | (#42690553)

For new screwups the soloution would be to just reject the push and let the developer sort it out.

For existing screwups it's not so easy. One of the characteristics of hash-based dvcs systems like git is that they make it REALLY painful to change history. You could generate new commits and blacklist the old ones but doing so would tip off all users of the repository that something was up and those users would still have their copies of the original commits.

Re:This is why developers are not sysadmins (1)

Hatta (162192) | about a year ago | (#42690097)

Or just leave the keys and let them learn their lessons the hard way.

Re:This is why developers are not sysadmins (1)

Anonymous Coward | about a year ago | (#42690107)

This is why developers shouting "give me full access now" should always be denied - there is a totally different mindset between developers and admins (or DevOps) when it comes to protecting things like SSH keys.

Both groups have similar (or certainly overlapping) technical skill sets, but have very different motivations.

ObXKCD: http://xkcd.com/705/

Re:This is why developers are not sysadmins (2)

h4rr4r (612664) | about a year ago | (#42690159)

The best system I have seen is not allow devs any access to production environments. All pushes done by sysadmin and dev boxes identical to production.

Re:This is why developers are not sysadmins (0)

Anonymous Coward | about a year ago | (#42691267)

The best system I have seen is not allow devs any access to production environments. All pushes done by sysadmin and dev boxes identical to production.

Now if only we could find super-competent admins that don't fuck things up left and right, and devs that could write documentation that the good admins can follow and design code that can actually be deployed instead of hacked-in-place, and management that doesn't insist on "hurry up and get it fixed right now, we will follow the normal process when we have time".

Re:This is why developers are not sysadmins (0)

Anonymous Coward | about a year ago | (#42690409)

And sysadmins don't do these kind of stupid shit? BS.
Along with this, people posted their .bash_history which is just as bad imo, and in one of those .bash_history's I noticed a "ssh sysadmin@some_ip_addr" so it's not like they are all geniuses.

You can still check all these bash histories by doing a google search:
site:github.com inurl:.bash_history

Re:This is why developers are not sysadmins (1)

h4rr4r (612664) | about a year ago | (#42690629)

Those people should just be fired. This is pretty much par for the course for the average new developer.

This demonstrates a critical flaw... (1)

Junta (36770) | about a year ago | (#42690545)

This happens both in private and publicly developed projects. All too often the developers do not grasp the fundamentals of security. If lucky, they grasp 'enable encryption' but it's exceptionally rare for them to understand things like mutual authentication and appropriate key management or even why a backdoor or fixed credential is very very bad news. The 'answer' in many companies is to tack on a 'security expert' to audit the code and do some penetration testing. While this is certainly not a bad idea, the security expert who is not a developer can only do so much. Additionally, that security specialist frequently ends up with an antagonistic relationship to the other developers because the developers will want to do things the ludicrously insecure easy way and the security specialist, conversely, will impose security but without much perspective for making the security as easy as it could be. As a common example, take SSL. Many developers will say 'enable SSL because it is secure, but disable all cert checking because it's beyond us'. SSL is nearly useless in that scenario. Security person comes in and rightly notices this is a dumb idea. Security person then forces develoers to turn their project into nagware so that user is well warned about the threat and maybe the user will do something like carefully curate their certificate management to avoid the nag, when in practice the user just trains to always click 'ok'. Meanwhile, a third option of secure, automated PKI chaining off some other solid trust relationship is missed because the required understanding and perspective are not shared among enough of the developer base.

The only way software can be entrusted to do things moderately secure is if solid principles of security are pervasive in the minds of all the developers. Then good security practices are done and frequently in a manner that is extremely unobtrusive to the user.

Re:This is why developers are not sysadmins (0)

Anonymous Coward | about a year ago | (#42690557)

Yes, github should be sued out of existence because of incompetent coders who only needed to make their repos private.

Re:This is why developers are not sysadmins (2)

segedunum (883035) | about a year ago | (#42690805)

The first thing you learn is that your private SSH keys are sacrosanct. Most developers seems to just go through a howto on how to generate a SSH key and don't think about anything after that. They're probably all using node.js or something.........

Re:This is why developers are not sysadmins (2)

19thNervousBreakdown (768619) | about a year ago | (#42691181)

This is why key management should be part of the operating system, and every piece of software that doesn't use those APIs should be suspect.

It's simply too big a subject to expect everyone who is in danger of falling prey to something similar (everyone who uses a computer) to manage on their own. If you know where every individual piece of software you run stores every single key, you are a very, very rare person. You're also probably mistaken.

Even if we started down the path, it would take a long time, that's no question. But I can think of no other alternative that has even an ounce of realistic chance of success.

Re:This is why developers are not sysadmins (-1, Redundant)

loufoque (1400831) | about a year ago | (#42691361)

Developers are the best sysadmins you can have, since they're actually somewhat competent.
It's just that they've got better things to do and are paid more.

Deserving (1)

Anonymous Coward | about a year ago | (#42690029)

Developers (using the term loosely) deserve whatever ill comes from checking in private keys. Public repo or otherwise

Re:Deserving (5, Insightful)

GameboyRMH (1153867) | about a year ago | (#42690057)

Exactly, GitHub shouldn't disable a site feature to protect the stupid.

Re:Deserving (1)

Anonymous Coward | about a year ago | (#42691517)

+5 Insightful? More like +5 Opinionated. Seriously modders, I fail to see anything insightful in that one-liner.

Search engines (5, Informative)

ArsenneLupin (766289) | about a year ago | (#42690035)

On google, the following search string still turns up a goldmine...:

site:github.com inurl:id_dsa

Idiots...

Re:Search engines (4, Funny)

robmv (855035) | about a year ago | (#42690183)

Stop, Google will shutdown search because of that

Re:Search engines (2)

ArsenneLupin (766289) | about a year ago | (#42690269)

Actually, in the glory old days of SQL injection, google did shut down search for certain patterns (such as inurl:cfm inurl:page_id or inurl:asp inurl:password). If you did too many searches for these, you got a captcha to prove that you were not a "bot"...

Re:Search engines (1)

Ysangkok (913107) | about a year ago | (#42690561)

intitle:index.of [google.de] used to work better too, though it kinda works today; I'm surprised.

Re:Search engines (1)

ArsenneLupin (766289) | about a year ago | (#42690793)

intitle:index.of

Interesting, it still finds lots of music. Weird that the MAFIAA hasn't discovered this yet, and sent them lawyer's love letters...

On a hunch, I tried my own search terms too, an I was quite surprised to notice that inurl:cfm inurl:page_id has several vulnerable sites on its second page [google.com] ...

Re:Search engines (1)

ArsenneLupin (766289) | about a year ago | (#42690841)

... and intitle:index.of confidential finds loads of pages too (most are false positives, but the very first one is definately "the real thing"..)

Re:Search engines (1)

Anonymous Coward | about a year ago | (#42691427)

In the really old days of the internet, you could do a search for root: and turn up a bunch of /etc/passwd files of boxes that set httpd to reply to anything. And if it was the REALLY old days, you could even use that information!

Proof... (1)

Ignacio (1465) | about a year ago | (#42690039)

...that even (supposedly) smart people can be stupid.

Re:Proof... (0)

Anonymous Coward | about a year ago | (#42690105)

...that even (supposedly) smart people can be stupid.

Or caught with Smartie Pants down.

Re:Proof... (2)

VortexCortex (1117377) | about a year ago | (#42690119)

I'm sorry, were you under the assumption that idiots can't write code?

Re:Proof... (1)

sdnoob (917382) | about a year ago | (#42690197)

I thought most of those lived in or near Redmond, WA and Redwood City, CA.

Re:Proof... (1)

ArsenneLupin (766289) | about a year ago | (#42690307)

Visual Basic monkeys live all over the world unfortunately. Only the jumping monkey lives in or near Redmond...

Re:Proof... (0)

Anonymous Coward | about a year ago | (#42690379)

That's so '90s. The current putdown phrase is "Javascript monkeys".

Re:Proof... (1)

Lisias (447563) | about a year ago | (#42690291)

In a environment where idiots write code, you will never see a coder calling "idiot" to another.

Been there, saw that.

(I got fired, by the wat - I wasn't idiot enough!)

Re:Proof... (1)

Anonymous Coward | about a year ago | (#42691135)

you will never see a coder calling "idiot" to another ... Been there, saw that... by the wat

I wasn't idiot enough!

Maybe you were...

I just saw this, sort of (5, Interesting)

slashmydots (2189826) | about a year ago | (#42690055)

I was cruising ebay yesterday and saw that one of the laptops had their windows license keys exposed in pictures in a readable format. I poked around some more and found that isn't terribly uncommon. Some people just don't think no matter what website it is.

Re:I just saw this, sort of (0)

Anonymous Coward | about a year ago | (#42690247)

It gets even dumber than that. Years ago people used to sell new copies of windows XP on ebay and have a picture of the license key. I have installed many copies of XP from a single XP cd by just searching eBay on Windows XP new.

Re:I just saw this, sort of (0)

Anonymous Coward | about a year ago | (#42690529)

I was crusing adult friend finder yesterday and saw that one of the girls had her breasts exposed in pictures. I poked around some more and found that isn't terribly uncommon. Some people just don't think no matter what website it is.

Problem? (0)

Anonymous Coward | about a year ago | (#42690065)

I don;t understand the issue.

It's all very cloudy to me.

Look at the pic (0)

Anonymous Coward | about a year ago | (#42690077)

None of these "private key" files in the posted pic on Twitter actually contain any key data

How many of those are Rails projects? (0)

Anonymous Coward | about a year ago | (#42690081)

Hey, let's be so lazy that user_id=1 is always the Admin user! Ohmygosh it makes testing so much easier and that all that matters!

overreaction? (3, Insightful)

Shavano (2541114) | about a year ago | (#42690127)

Seems like the wrong response. Instead of killing search, why not just erase the keys files and lock out the accounts of the offending devs?

Re:overreaction? (3, Insightful)

h4rr4r (612664) | about a year ago | (#42690209)

Because some of these might be test keys or place holders. If the key is not valid on any system and is just test data, it should not be a big deal to post publicly.

Re:overreaction? (1)

Bogtha (906264) | about a year ago | (#42690423)

Example: the keys for Vagrant [github.com] . Vagrant is a system for managing virtual machines for development purposes. The ssh keys are used to facilitate passwordless login. They aren't typically exposed to the outside world, and they are clearly labelled as insecure.

Re:overreaction? (1)

h4rr4r (612664) | about a year ago | (#42690645)

That thing should really generate new ones on install.

That way there are no keys to expose to the world that anyone would know.

Re:overreaction? (1)

Bogtha (906264) | about a year ago | (#42691195)

One of the things people do with it is build base boxes, which are preconfigured virtual machines, and share those base boxes for other people to build upon. In order to do so, the people who receive these base boxes need the private keys they are configured with.

You could distribute the private keys with the base boxes, I suppose, but then you are stuck sharing multiple files instead of just one, and you can't install a base box by running one single command with a URL argument any more. It increases the complexity.

Re:overreaction? (0)

Anonymous Coward | about a year ago | (#42690233)

That's just silly. Github shouldn't go about banning people because of how they run their own projects. And they can't just go erasing important files out of someones repos either.

Re:overreaction? (0)

Anonymous Coward | about a year ago | (#42690301)

Yes, it's the wrong response in that it's not a response. Search being down is unrelated, RTFA.

Re:overreaction? (0)

Anonymous Coward | about a year ago | (#42691383)

Why not let people check what they want into source control? It isn't their fuckin' problem.

Stupid people... (3, Insightful)

Lisias (447563) | about a year ago | (#42690195)

These stupid people should be had their accounts suspended.

People should be accountable for their actions, and these idiots are potentially compromising third party data security!

ICO didn't fined Sony for the information leak on that Anonymous attack? Why in hell GITHUB user's should be less accountable for things THEY ARE FSCKING COMMITING in their accounts?

Re:Stupid people... (1)

gajop (1285284) | about a year ago | (#42690477)

Why would they have their accounts suspended? It's their right to share that.. even if it's pretty stupid.
I assume search will be back eventually, it's probably just a temporary measure until they implement ways to inform the users of a potential common* misstep.

*It really is common when you see hundreds~thousands of .ssh and .bash_history files.

Re:Stupid people... (0)

Anonymous Coward | about a year ago | (#42691293)

Not far enough, they should be doused in gasoline and BURNED!

github did not take search down because of this (2, Informative)

Anonymous Coward | about a year ago | (#42690207)

According to their twitter and status pages, the search is currently unoperational due to problems with their search cluster. They recently released changes to their search including, I believe, a move to ElasticSearch. The linked article says as much, too, so yet another fail in a slashdot summary.

Nothing has changed... (5, Funny)

140Mandak262Jamuna (970587) | about a year ago | (#42690275)

Back in the days when I was the root (of all evil according my fellow grad students) of our lab, one of the constant problems was people blindly doing chmod 777 .* on the $home. They have .emacs or .profile or .cshrc that was customized ages ago by some grad student, and they want to share it with a new student. Somehow they stumbled on to "chmod 777 .*" as a solution to all their file sharing problems. Now this "magic command" was also being blindly passed around without worrying about security implications. Oh, yeah, they think they are clever and tape the login credentials to the underside of the keyboard and laugh at secretaries who tape it to their monitors.

Looks like these grad students have all growned up and uploading it all to the cloud.

Re:Nothing has changed... (2)

h4rr4r (612664) | about a year ago | (#42690387)

When people did stuff like that in my sysadmin classes we were encouraged to teach them a lesson. Far better to edit their login script to log them right back out than delete their homedir contents, or change their path so they got other versions of common programs. Probably the meanest was to make it so instead of calling the work submission script it called rm on whatever they were trying to submit as their classwork.

Re:Nothing has changed... (2)

Frohboy (78614) | about a year ago | (#42690751)

A subtler prank that I pulled on a friend who left himself logged in to one of the public undergrad labs (where there was the risk that an actual asshole would delete your stuff, send email as you, or something similarly cruel) was to add "echo 'sleep 1' >> .cshrc" to the end of his .cshrc before logging him out. I chuckled to myself, and then forgot about it.

A week later, when it was 5 minutes before a submission deadline and he was yelling at the terminal to finish logging in (since it was taking 2-3 minutes for the prompt to appear by that point), I realized that I had probably gone too far.

Re:Nothing has changed... (4, Funny)

WankersRevenge (452399) | about a year ago | (#42690775)

Yeah ... I was "that guy". The first time I installed Linux in 2000, I was annoyed that I needed "permission" to write to a directory outside of my home directory. I was coming from a Windows world, after all.

I solved this "problem" by chmod 777 the entire filesystem. Hah. Problem solved. Needless to say, I couldn't start the machine back up again. I'm guessing it killed itself from the shear embarrassment. After that, I decided it may be in my best interest to read the manual.

I'll do that one of these days :)

Re:Nothing has changed... (0)

Anonymous Coward | about a year ago | (#42691121)

This is the reason that modern versions of ssh will refuse to use a private key if it is world-readable. (Of course, people who are just smart enough will chmod it back instead of generating a new key.)

Perhaps it is time to take the bold step of ensuring that user-private keys aren't owned by the user since obviously users can't be trusted to protect their own assets.

Open Secret Server to the rescue! (1)

herberts (648935) | about a year ago | (#42690461)

This is exactly the problem OSS (http://github.com/hbs/oss) is trying to solve!

Deleting files is shockingly hard in git (1)

bsberman (2704141) | about a year ago | (#42690523)

Maybe if it weren't so goddamned complicated to remove a file from the history of git, this wouldn't happen. Explain to me, in a series of commands, how I would remove a hypothetical "secret_keys.txt"?

Re:Deleting files is shockingly hard in git (0)

Anonymous Coward | about a year ago | (#42690631)

dd if=/dev/zero of=/dev/brain

Re:Deleting files is shockingly hard in git (0)

Anonymous Coward | about a year ago | (#42690677)

https://help.github.com/articles/remove-sensitive-data

It's difficult to impossible to do it when someone has already cloned your repository.

Re:Deleting files is shockingly hard in git (0)

Anonymous Coward | about a year ago | (#42690731)

Much easier than in SVN (which it is, AFAIK, impossible)..

git filter-branch --index-filter 'git update-index --remove secret_keys.txt' ..HEAD
git push --force --verbose --dry-run
git push --force

Re:Deleting files is shockingly hard in git (1)

Anonymous Coward | about a year ago | (#42690855)

Here's a guide! https://help.github.com/articles/remove-sensitive-data

Not so many (3, Insightful)

Shimbo (100005) | about a year ago | (#42690609)

Hundreds of keys from a million accounts; less than one in a thousand developers screwed up. Call a doctor at once! Then ask him about outliers in large populations.

A big mess to clean up (4, Informative)

NightHwk1 (172799) | about a year ago | (#42690699)

git rm id_rsa*; git commit -a -m "problem solved\!"

Not quite. They're already out there. The keys are still in the revision history. People have forked and cloned it.

Hopefully the developers who created these keys know that besides removing them from the repo, the keys can no longer be used. They must be removed from every .ssh/authorized_keys file, every service like Github that uses them for deploying code, etc.

Proof Github took search down? (2)

gajop (1285284) | about a year ago | (#42690747)

This doesn't suggest github took anything down on purpose: https://status.github.com/messages [github.com] .
Seems to me they were just experiencing some technical difficulties from all the people sharing those search links and having a laugh at the stupids...
I skimmed over the github site and didn't find anything that would suggest otherwise at least.
Of course I didn't read the articles because they seem badly misinformed and confuse private keys with passwords.

So... (0)

Anonymous Coward | about a year ago | (#42690789)

Are people going to be demanding a class action lawsuit against the administrators of GitHub for "failing to protect their security," or is that only reserved for Sony and other hatreds-du-jour?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...