Hacker News Reader

Hacker News

Comment by cllns | Hacker News Reader

Full thread

cllns

It'd be nice if github would suggest adding secret_token.rb to .gitignore when it's uploaded.

View on HN

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

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.

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.

Maybe not so intrusive, but they could add it to https://github.com/github/gitignore/blob/master/Ruby.gitigno... . Not sure how many people use that repo tough.

Version control being hard-coded with an exception for a particular framework of a particular language... I see the benefits, but I am deeply wary of it. What if the filename changes in the future? Does GitHub somehow have to detect versions?

I'm not sure if you're joking. Ruby on Rails projects aren't the only ones that have files that shouldn't be made public on GitHub.

GitHub will already generate a .gitignore file when you create a repository on its website. It would be nice if the .gitignore file was based on the type of project being created. And it would be nice if it gave a warning when files that are in the default .gitignore were being pushed to the repo.

If the filename changes in the future, who cares? It defaults to the current situation where no warning is given, but potentially improves security in many cases. And it's not a big deal to add another file to a list.

GitHub will already generate a .gitignore file when you create a repository on its website. It would be nice if the .gitignore file was based on the type of project being created.

Right, but how does it know that? There is no "Create Ruby on Rails project" command in git. How will it know what to include? Will it have to scan and somehow detect that it's an RoR project? And check the version of it?

Much simpler to leave this stuff to a RoR-specific tool. Maybe the .gitignore should be a default file when creating an RoR project.

I'm not sure if you're joking. Github is Git as a service... it's not in the business of software best practices.

Are you suggesting that Github starts tracking all major frameworks, all versions of said frameworks, and the files that should maybe not be version controlled within each of those frameworks/versions?

Or rails could suggest additions to .gitignore (and equivalents for svn).

Or,since we're proposing changes to Rails* how about the Rails people fix it properly, and put the configuration somewhere outside the source tree?

*(which is much more sensible than proposing changes to git/github in response to a Rails default configuration problem)

Would be even better if secret_token.rb's data was kept in the database.

Reply on news.ycombinator.com