I think one of the common security issues strongly hinted at by this blog post is Rails' secret_token.rb security debacle[1]. Basically Rails has a file called secret_token.rb containing what should be a complete secret, but the default Rails .gitignore doesn't ignore it and as far as I've experienced, none of the main introductory Rails tutorials mention it. So a lot of people accidentally publicise it on GitHub, and this facilitates exploits of some of the recent Rails vulnerabilities.
I've made this mistake although fortunately with an unpublished app to a private repo but I'd still like to fix it.
My ideal solution will probably be to:
1) Look for an environment variable
2) Look for a file in the project config or root named: secret-git-ignore-this-file (or something similar)
3) If it fails to find either of then generate a new secret with secure_rand
4) If running on Heroku write it to the environment variable (I think this can be done and should persist although I'll need to check the documentation).
5) Otherwise write it to the secret-git-ignore-this-file
If/when I get round to this I'll probably try to put it on Github for others to use although if anyone knows of any good published solutions that do something like this that would be even better.
Basically it adds a yml file, that is added to .gitignore, with configuration settings that get added to ENV. It can even send your environment variables to Heroku using a Rake task. There are some examples on the page. You can use it to have different secret keys depending on your Rails environment as well.
Even if #4 is possible (I rather doubt it), you shouldn't really do that. It breaks the barrier between code and configuration by making the former influence the latter.
Such approach is simply not scalable. I don't know what secret_token.rb is (I do Python) but if it's anything like an HMAC key for encrypting your session cookies, your app will break once deployed to more than one frontend because the cookies will suddenly become tied to specific dyno.
Yes it is for the session cookies. You are right that it won't work well for multiple frontend servers but that isn't going to be an issue for this current app. If it is written to the Heroku environment it should be available to all dynes I think.
I can rethink the solution if I need scale. I don't really think of it as config as I don't care what the value is just that it is consistent on any given host.
I've had this issue affect me once or twice in the past (fortunately only with debugging settings, not secret keys). The solution for me was to create a pre-commit script for git that looks through the diff of my commit for a special token, and aborts the commit if the token was found. Now when I make a change to a bit of code that shouldn't be committed, I'll throw in the token as an additional sanity check.
For someone who had never done any git scripting before, I was surprised at how easy it was to put together - just 9 lines of bash for the simplest thing that could possibly work: https://gist.github.com/4513374
More specifically, on r/netsec someone who used that search found a .zsh_history file that contained mplayer invocations with file names that imply child porn. This caused quite a stir.
[1] http://biggestfool.tumblr.com/post/24049554541/reminder-secr...