CODEWITHSUNDEEP
securityopen-sourcegithub
Yevgeniy Brikman
Yevgeniy Brikman

Reputation: 9361

Open source projects: what to do with private/secret config data?

I'm considering open sourcing the code for a live website of mine on Github. Up to this point, I've been storing the code in a private repo and my only concern is that there are a few configuration files related to my production environment (DB passwords, API keys, etc) that I don't want to be publicly visible.

What is the typical approach for open sourcing such projects without exposing private data? Do you just maintain two repo's, a public one and an identical private one with the added private data, occasionally merging between the two?

Upvotes: 6

Views: 664

Answers (2)

Troy Hunt
Troy Hunt

Reputation: 20387

Logically, there's really only two things you can do without disclosing your sensitive info:

  1. Not put the info into public VCS at all.
  2. Put the info into VCS in a cryptographically secure fashion.

I personally wouldn't want to duplicate repositories and if you need to deploy directly from VCS then you're pretty much left with option 2. Obviously it will depend on your framework, but in .NET, for example, I'd be ensuring your connection strings and API keys are stored in the web.config then it's properly encrypted (I talk about this in the "Encrypt sensitive configuration data" section of OWASP Top 10 for .NET developers part 6: Security Misconfiguration).

With this approach, you're putting the required info into the config file such that it can execute successfully on the machine where the encryption occurred but not elsewhere. Try running the app on another machine and an exception will be thrown due to the difference in keys.

Upvotes: 0

Rafe Kettler
Rafe Kettler

Reputation: 76955

In the case of Git, I'd recommend you add rules to your .gitignore to ignore files that contain sensitive info (.hgignore for Mercurial). Try to keep the sensitive info in one place as much as possible (e.g. a settings file). If you worked with a web framework, this info is usually in one file (for example, in Django, there's a settings.py file with DB info, secret key, etc.) If you have sensitive info ingrained in various parts of your application, factor that info out into some kind of configuration file or object.

If you want people to still know where the data is coming from, include an example or dummy file with fake data with a notation somewhere (either in the file or in the README) that the file will have to be changed. You could then name the file, for example, settings.py.example and ignore the real settings.py.

Keeping multiple repos is a bad idea. Just leave out sensitive data and make sure you make it obvious that it is missing and what is missing, so that people can still reuse your work.

Upvotes: 8

Related Questions