Hacker News Reader

Comment by jcoder | Hacker News Reader

No thanks. The last thing I want is my version control host getting opinionated about my application domain.

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.

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.

What if they just gave you a onetime warning instead?

I like this game: What if that annoyed the pants off some people?

You're kidding right?

Then they should surely add it.

People so easily annoyed by trivial (yet potentially helpful) things should be annoyed as much as possible by the rest of us.

I think beering was following the old adage:

you can annoy some of the people all the time, or you can annoy all the people some of the time. You can't however annoy all the people all the time.

Reply on news.ycombinator.com