How do I open source my Rails' apps without giving away the app's secret keys and credentials

I have a number of Rails apps hosted on GitHub. They are all currently private, and I often will deploy them from their GitHub repository. I'd like to be able to make some of them open source, just like t开发者_运维知识库he ones you can find on http://opensourcerails.com.

My question is: How can I make these repositories public without giving away super secret credentials?

For example, I can look in /config/initializers/cookie_verification_secret.rb and see the cookie secret for nearly every one of them. I don't understand how this is acceptable. Are these users all changing these values in their deploy environments somehow?

Some users even expose their AWS secret and key! Others will instead set their AWS secret to something like:

ENV['aws-secret']

although I'm not sure at what point they're setting that value.

So, what are the best practices for open sourcing your Rails app without compromising your app's security.

I recently went through this with one of my own apps. My solution was to store anything secret in a git-ignored YAML config file, and then to access that file using a simple class in the initializers directory. The config file is stored in the 'shared' folder for the Capistrano deployment and copied to config at each deploy.

Config store: http://github.com/tsigo/jugglf/blob/master/config/initializers/juggernaut.rb

Example usage: https://github.com/tsigo/jugglf/blob/6b91baae72fbe4b1f7efa2759bb472541546f7cf/config/initializers/session_store.rb

You may also want to remove from source control all history of the file that used these secret values. Here's a guide for doing this in Git that I used: http://help.github.com/removing-sensitive-data/

If you're using foreman, put an .env file in the root of your app. (foreman docs)

.env will have

AWS_SECRET=xxx
AWS_ACCESS=yyy

Then when you need to use the keys, insert:

ENV['AWS_SECRET']
ENV['AWS_ACCESS']

Though it's important that you don't commit this .env to your version control. So if you're using git, add the .env to your .gitignore.

Bonus round! - Heroku

If deploying to Heroku, these environment variables need to be configured in the Heroku environment, too. There are two options:

1. Manually add the keys through the heroku config:add command
2. Use the heroku-config gem to synchronize your local environment variables, both ways.

Not storing any secret value at all. At any point in the history of a Git repo.
Those values should be stored elsewhere, leaving only template config files versioned, along with a script able:

• to read the right values from the external repo
• and build the final config file complete (with the secret values in it)

By keeping the tow set of data separate (sources on one side, secret values on the other), you can then open source the sources repo without comprising any secrets.

I actually took a hint from your question, using ENV.

I had three different secret values that I didn't want made available. They're the app's secret token of course, and Twitter's consumer key and secret. In my secret token initializer:

KinTwit::Application.config.secret_token = ENV['SECRET_TOKEN']

Twitter.consumer_key                     = ENV['CONSUMER_KEY']
Twitter.consumer_secret                  = ENV['CONSUMER_SECRET']

I'm hosting my project on Heroku, so I added these as configuration variables to Heroku.

[03:07:48] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_KEY=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v7
  CONSUMER_KEY => ub3rs3cr3tk3y
[03:08:40] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_SECRET=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v8
  CONSUMER_SECRET => ub3rs3cr3tk3y
[03:08:57] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add SECRET_TOKEN=ub3rs3cr3tk3y
Adding config vars and restarting app... done, v9
  SECRET_TOKEN => ub3rs3cr3tk3y

Now, the values are ready on my next push. But, what if you aren't using Heroku? I'm obviously not an expert on every single rails deployment (jeesh, not even a Heroku pro), but an example of this would be doing a db:migrate for testing.

$ RAILS_ENV=test rake db:migrate

The KEY=value pair before the command sets the environment variable, so running this command, echo ENV['RAILS_ENV'] would print test. So however this is set up in your environment is how you would do it. But, the environment variables aren't in your code, so that's the trick.

[EDIT - The following method has the annoyance of having to switch to the Production branch to run "rails server" in order to include necessary cookies. Thus, making edits while the server is difficult... and I'm still looking for a good solution]

After further investigation, I think the solution I was looking for was to exclude anything that stored a secret value from my Git repo's master branch (just as @VonC said). But instead of then reading from those files in a separate repo, I simply create a new "production" branch and add them to that.

This way they're excluded from Master and I can push that to Github or some other public repo just fine. When I'm ready to deploy, I can checkout the Production branch and merge Master into it and deploy Production.

I need to be able to do this because Heroku and other hosts require a single git repo to be pushed to their servers.

More information here:

http://groups.google.com/group/heroku/browse_thread/thread/d7b1aecb42696568/26d5249204c70574