views:

100

answers:

2

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?

+1  A: 

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.

Kornel Kisielewicz
+2  A: 

Your app should use a config file. This config file is loaded at runtime and shouldn't affect compiling. The allows users to download a binary and still use their own api key.

As Kornel says, you can include an example config file with a fake API Key, in your source control.

Another option, you could talk to the people running the webservices and ask for one of two things.

  1. A temporary key, that only works for limited functionality. That would let users see basic functionality of your app, but some people would never update the key and just use the basic stuff.

  2. Talk to the webservices to see if you they will give you a special API Key for your application. The open source version would require users to enter their own. But your binary could use a standard one.

The thought of using a config for api key's, isn't new or unheard of. Bit.ly services do it. And all the open source applications I see that provide use with Bit.ly ask for your username and api key before you can use it.

This is no different?

Insanity5902
The problem with using a config file is that I'm actually distributing the program in it's compiled, usable form elsewhere. If I were to go the config-file route, I'd have to distribute the program with a config file filled with the API keys.
callingshotgun
To be honest, nothing prevents a savvy hacker to rip out your API keys even from the compiled form.
Kornel Kisielewicz
What operating system are we talking about? All modern system's have a installer system and they all handle config files one way or another. You don't have to ship it with workable API Keys. I've seen several projects that won't run until the key is a valid key. The application just check that the key works upon startup. If you are wanting to ship a demo version of some sorts, you could try to provide a temporary one. I've updated my answer with this thought
Insanity5902