This isn't to say that a developer for one of these frameworks couldn't easily overlook adding the files with secret_tokens in them to the .gitignore.
Rails does the right thing by putting the secret token in it's own file that's even _called_ secret_token.rb (it could have just jammed it in the middle of config/application.rb or something instead, where it would be even easier to miss and/or not realize it should be kept private). So I don't know it's people who don't 'understand' it -- whether you understand it or not, the file is named "secret_token", if you actually look at a file listing and think about "should this be kept secret?", the answer is obviously yes even if you know nothing.
But... there's still a lot going on, and it's something easy to forget about, since you ordinarily _never_ need to think about the secret_token.
Should have been called "secret_token.yml". Should live in the config, or even better, a "secret_config" top level directory, not a subdirectory.
But I think it's not unreasonable to have expected it was clear that ./config/initializers/secret_token.rb was a file to initialize a secret token, that included a secret token in it.
Usually what ends up happening is people build less secure systems because they don't understand those basics. Giving people less tools don't equate in them building better solutions on their own.
Rails deployments aren't leaking their ssh keys or database content because that is stored separately. To paraphrase the title: these things are stored separately for a reason.
Get this thing out of the source, guys.
secret_token.rb is placed where it is, because it is a initializer.
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 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.
Just not publicly viewable
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.
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.
People so easily annoyed by trivial (yet potentially helpful) things should be annoyed as much as possible by the rest of us.
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.
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.
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?
*(which is much more sensible than proposing changes to git/github in response to a Rails default configuration problem)
Note that not all of those results are necessarily vulnerable, for example, https://github.com/hotsh/rstat.us/blob/master/config/initial... loads the secret key from the environment, and https://github.com/GreenplumChorus/chorus/blob/master/config... loads it from an ignored file (like the article). I would estimate the real number of projects to be somewhere less than 3000, with about 1400 being on Github. This also assumes that these are all actually production keys.
Just to reiterate, I do believe that this is a legitimate problem even now, but I just wanted to note the age of the article and to refute the claim that this is the first mention of the issue.
Yes, and using secret_token.rb is also way faster.
1. Your configuration is backed up along with your data.
2. You can share configuration with multiple applications easily.
3. Use postgresql's LISTEN/NOTIFY to tell your applications about new configuration changes in real-time.
4. Your configuration is as secret as your data.
It also pushes your ENV vars to Heroku with one command. Pretty neat and simple.
In case you want to check it out https://github.com/laserlemon/figaro
Secrets (keys, passwords, tokens, etc) don't belong in the source tree. If you put them there by default, one day you (or one of your users) is going to "forget" and be in a world of hurt.