What if any source code of a rails project should be obscured even for an open source project? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question

This was a hard one to search for. If I have an open source rails web application project whose source code is publicly hosted, like on GitHub, what information should be obscured or swapped if that application is to be run in production at a public website? My assumption is that things like config/initilizers/secret_token.rb, any authentication salting stuff, and the database lo开发者_开发百科gin information should not be the same in production as in development. What other precautions should be taken to ensure that the production site is not vulnerable to people fiddling with the sessions or anything else I am not considering?

---

Rails-specific Sources of Sensitive Information

Scrub sensitive information out of:

• config/environments/*.rb
• config/initializers/cookie_verification_secret.rb
• config/initializers/secret_token.rb
• config/initializers/session_store.rb
• any files added to support third-party libraries, such as config/memcached.yml
• config/database.yml
• db/seeds.rb
• any rake tasks in lib/tasks.
• test/fixtures/*

General Changes

Including this just because I think it's a good list of things to keep in mind for releasing open-source software that you also have in production.

• Remove sensitive information:
  • password salts
  • default user credentials populated by code or seeds
  • authentication information to any external server or service
    • databases
    • third-party APIs
    • eCommerse solutions
  • any seeded data that would potentially publicize trade secrets
• Test code throughly for exploits. If they are in your code and your code is available to the public, people will find them and will know how to compromise your site.
• Clean up the code. The code is a form of publicity for your site; it's is one of the many things that will represent your site/company. Make sure you change variable/function names/error messages/seeded data/etc that were written out of humor or frustration but that would look bad to the public.
• Actively contribute your enhancements and bug fixes to the project and respond to external requests for fixes/enhancement or even pull requests for those who have solved a problem themselves. This keeps the project active and also helps with the publicity angle.
• Make sure you give credit where credit is due. Now that your code is public, people will know if you've utilized third-party code/libraries. If such code came with attribution clauses in their license agreements, make sure your project complies with those agreements.

---

The previous answer by Shaun is very thorough.

Additionally I'd like to recommend to use .gitignore to your advantage to avoid ever committing files with sensitive information.

Any file containing API keys or passwords, etc. should be in .gitignore. Typically this includes:

database.yml
log/*
tmp/*

If you have API keys assigned to constants in code files, I'd recommend putting all the API keys, passwords, etc. into a site.yml file. Then add this file to .gitignore and add an initializer to parse this file into a constant. Use that constant to access the secret data.

For example:

config/site.yml:

hoptoad_api_key: ABCDEF1234567890

config/initializer/01_site.rb

SITE = HashWithIndifferentAccess.new(YAML.load(File.open(File.join(Rails.root, 'config', 'site.yml'))))

config/initializer/hoptoad.rb

HoptoadNotifier.configure do |config|
  config.api_key = SITE['hoptoad_api_key']
end

Note that the initializers are run in alphabetical order. If you need the SITE constant in other initializers, be sure to name the file that reads the configuration with a leading number so that it gets run first.

To be more user friendly for an open source project, you should include a database.yml.sample and site.yml.sample file with examples and/or explain needed configurations in your README.