For a pet project, I develop a desktop application which requires API keys from several different webservices.
I’ve been going through and preparing this application to become open-sourced and run across the problem of what to do with those keys.
The problem is this: My understanding is that these API keys should not be visible to anyone using the application or viewing/modifying the source code. From the webservice’s end, these API keys are used to identify applications accessing their API, and allow/block usage as appropriate. In most of the TOS’s for receiving these keys it’s actually explicitly stated that the keys must not be shared with the world.
Currently all my keys are hard-coded, but at I’m at an impasse as to how to handle the situation of private keys in an open-source application:
-If the keys remain hardcoded, they’ll be publicly visible as soon as my source code is.
-I can’t really omit the source file with the keys from the code distribution, since then
it won’t compile. This technically solves the problem, but introduces a new, unacceptable
one.
-If I push the keys off to a .ini or other config file, and simply not include that file
in my public code repository, it would still have to be distributed with the binary of my application in order for the app to function, so my keys would be visible in the application distribution instead of the source distribution. Not an improvement. Any encryption gymnastics I attempted to utilize on this INI file would be adding the complexity for anyone attempting to modify my code.
So, with regards to my codebase (currently under Mercurial for version control), what’s the best way to manage everything so that the code can be public, but my keys stay private?
Don’t know what language you are using, but for example in C/C++ you’d add a include file with the API keys, and then leave it out of source control, instead add a bogus file with explicitly fake API keys. Most languages have one or the other way to include files.