Hacker News Reader

Comment by cllns | Hacker News Reader

Care to elaborate on why?

Github's tagline is currently "Build software better, together." Wouldn't this help people create better software?

I'm not saying they should automatically add secret_token.rb to gitignore, just that they could let you know you might not want to do that.

View on HN

I don't think the answer is having GitHub do anything about it. The word has to be spread, yes. But not that way. Developers need to know about the importance of all their files and their security at development, else just think of what will happen when GitHub is not around or when they use another form of Git, etc. Problems need to be solved from the root and that means teaching developers to be more security aware, not making tools that will make said awareness easier to forget.

But wouldn't this be teaching developers? They upload the file and Github explains to them that it should be kept secret, and the developer has the opportunity to revoke the file. That sounds like the ultimate way of 'spreading the word', and if Github does disappear, they will have made people more aware. Not to mention it won't affect people who have been doing this all along.

Out of the 3000 repositories which I estimate to be affected by this issue (using Google and eliminating some common techniques used to circumvent the problem), I estimate 1600 of them are not on Github. Even if Github does its best to remove the issue completely, I don't believe it will have a huge impact.

I believe that a better idea is to fix this in Rails. Why is a secret key loaded from the configuration directory? I agree with ajross's comment (http://news.ycombinator.com/item?id=4970347).

This isn't to say that Github should do nothing to control the problem, but more must be done than just that.

Warning half of the project owners/maintainers that this is a problem won't have a huge impact?

Well yes, it could be teaching developers. But you would be teaching a single solution for a single problem. I think it would be better to entice solutions that target the bigger issue on security awareness. All this new tools that make it so much easier to develop complex applications have huge benefits, but I believe they are also pushing new developers away from understanding the concepts behind what they are doing. As someone who started as a designer and grew on my own into development, I've seen this issue first hand.

`rails new foo` generates a `.gitignore` file. That's where this belongs.

Not entirely, because you do need the file to startup your application. Which makes it a concern that should be checked in imo.

Just not publicly viewable

"Checked in but not viewable" is called a private repo.

If it's a public repo, don't check it in. I don't think Github should try to create a manifest of all "dangerous" files.

Really, best practice is to not check in sensitive values to your repository, ever, and instead use environment variables or symlinks to shared files via Capistrano to set these values in your application.

Reply on news.ycombinator.com