Live data from Hacker News

Private keys committed to Github repositories

github.com

21–30 of 31 posts

Re: Private keys committed to Github repositories

#21

Many of the items on that list are actually public keys, which should be perfectly safe to share to the world in a Git repo, but there are definitely a few private keys in there as well.

And most of which are "demo app" or "assignment app" or some kind of testing /demo use key in an application that deals with ssh in its processes. There also isn't any apps above 100forks, so nothing widespread to worry about. (add forks:>100)

Reminds me of google hacking: www.hackersforcharity.org/ghdb/ (which is way more fun)

Re: Private keys committed to Github repositories

#25

I knew this was going to happen, i'm sure other goodies will be found too.

Lots of people still push their Rails secret_token.rb to their GitHub-account: https://www.google.com.au/search?q=secret_token.rb+site%3Agi...

But there is a certain probability that the token on the GitHub-page is not identical to the production site's token.

(afaik, the token is digested with the user's ID and stored in the user's cookie so a user cannot change his ID while he's signed in - knowledge of the token can let you change your ID to whatever you like)

Re: Private keys committed to Github repositories

#27
post #19
post #4

Earlier quoted context omitted.

Seriously. It looks like people have added their private keys to (public!!!) repos, and voila, a search allows others to find that.

I had a dev send me his. I guess he doesn't understand the whole key-thing. Now he doesn't log in to my server. Just sends me a zip-file that I unpack and test. sigh.

On re-reading, I need to clarify: I asked a dev for his public key so I could give him access to my server, and he sent me his private key. Yikes!

Re: Private keys committed to Github repositories

#28
post #18

for those saying that github or git should have a default rule preventing private keys from being committed, I say: lolwat? private keys are private. these people -know- that they are pushing a git repo to a very public site. as such, they should recognize that * is going to be visible in their dotfiles repo. it's not git or github's fault that users are doin it wrong!

That's terrible logic, akin to Apple's "the iPhone 4 isn't defective, you're just holding it wrong." If a product is confusing your users, you should improve the UX to increase its usability. Adding a default .gitignore file with some sensible defaults has no negative trade offs. If you really do want to commit your .ssh folder, just remove that line from your .gitignore. I will admit that adding .DS_Store, while con…

wait so your saying github should stick a default .gitignore file in there and bloat it just for the extremely rare case that a user commits and pushes their entire home folder?

Even more rare than that is the user being dumb enough to not consider all files in the home directory before pushing to a public site. I'm sorry but I definitely agree more with the other guy's logic than yours.

You say it has no negative tradeoffs? I say besides changing the whole game (as of right now github does not subject me to a single line of opinionated code) some projects are meant to be small. Sure you can just take out the github .gitignore but thats an extra step. I'm really tired of the stance that we should make development so easy even someone who refuses to RTFM can do it. I'm all against re-inventing the wheel, but dumbing things down like that is not something I can get behind.

Re: Private keys committed to Github repositories

#29
post #28

Earlier quoted context omitted.

That's terrible logic, akin to Apple's "the iPhone 4 isn't defective, you're just holding it wrong." If a product is confusing your users, you should improve the UX to increase its usability. Adding a default .gitignore file with some sensible defaults has no negative trade offs. If you really do want to commit your .ssh folder, just remove that line from your .gitignore. I will admit that adding .DS_Store, while con…

wait so your saying github should stick a default .gitignore file in there and bloat it just for the extremely rare case that a user commits and pushes their entire home folder? Even more rare than that is the user being dumb enough to not consider all files in the home directory before pushing to a public site. I'm sorry but I definitely agree more with the other guy's logic than yours. You say it has no negative tr…

I don't know about you, but I've never had a git repo that didn't have a .gitignore file. Having one automatically would make me do one less step.

This doesn't dumb down programming. It improves UX for everybody, while also improving security for beginners. Why does GitHub offer to autogenerate a readme file? Because it's convenient. That doesn't dumb down programming for anybody.

Re: Private keys committed to Github repositories

#30
post #28

Earlier quoted context omitted.

wait so your saying github should stick a default .gitignore file in there and bloat it just for the extremely rare case that a user commits and pushes their entire home folder? Even more rare than that is the user being dumb enough to not consider all files in the home directory before pushing to a public site. I'm sorry but I definitely agree more with the other guy's logic than yours. You say it has no negative tr…

I don't know about you, but I've never had a git repo that didn't have a .gitignore file. Having one automatically would make me do one less step. This doesn't dumb down programming. It improves UX for everybody, while also improving security for beginners. Why does GitHub offer to autogenerate a readme file? Because it's convenient. That doesn't dumb down programming for anybody.

Correct, but having a line that ignores .ssh is bloat in 99.99% of cases.

The key word in your second point is 'offer'. If they were to protect these keys from being pushed they would have to interfere with your first push and add a line to your .gitignore, which you would then have to remove EVERY TIME... if your a developer I don't know how at this point your not like "eh, actually I don't really feel like doing that in every project, that would be annoying".

I would also argue that allowing newbs to become developers without realizing that they are ignoring private key files inside their git repo is just allowing them to continue on to become developers who are not security conscious. You could of course argue back that having to take .ssh/ out of your .gitignore for every project you do hammers the point home for everyone, and it sure would! I don't believe most of us need that, and if that is your idea of improved UX then please don't ever work with me ;) (I'm j/k about that by the way, tabule looks pretty nice and this is all just my opinion, please don't take it personally. I would welcome an opportunity to work with you... just don't go adding .ssh/ in my .gitignore!! :P)

Post reply on HN