Most of my public code begins its life in a private repository. This is because, more often than not, I’m storing security credentials in a static file and don’t want anyone abusing my credentials.
Like most developers, I’m lazy. It’s easier to define a root-level constant with an API key or dashboard password than it is to program an interface for setting and storing those credentials. Unfortunately, it means I can very easily slip up and distribute those credentials to the world.
Case-in-Point
A couple of weeks ago, I built a quick little Node.js prototype that uses Tri-Met’s public API to fetch arrival times at a particular bus stop. I further extended the app by wiring it to a Twilio endpoint so that it will grab the bus stop ID from a text message – and respond to the sender with another text containing their stop information.
I was very proud of the application, and quickly moved to write up how I’d prototyped it in an afternoon. I pushed my code to GitHub and waited for the post to auto-publish.
Then a friend reminded me I’d pushed both my Tri-Met and Twilio credentials to the GitHub repository. I couldn’t sleep.
I quickly deleted the repo and hoped all would be well. I couldn’t just delete the credentials and push the change; GitHub would still have a copy in their revision history. Flushing the entire repository down the drain was my only option. I moved it back to a private repo on Beanstalk and left it at that.
@EricMann come on, you can’t post that and not link to the code in the post! Is it on GH?
— Travis Northcutt (@tnorthcutt) September 23, 2014
Obviously, people wanted to see the code. But my laziness had resulted in a repository I couldn’t actually publish.
The Resolution
Thankfully, someone pointed me to an article on using environment variables with the system hosting my running code. I was able to configure an environment variable for each piece of my authentication credentials, then could reference them within the application.
No more hard-coding!
I created a new repository with no history and transplanted my now-clean application to the new repo. I pushed it to GitHub for the world to see, completely confident that no one can use the code there to access my accounts with Tri-Met or Twilio without my permission.
It also taught me a very important lesson about code organization. I rarely, if ever, hard-code my credentials any more. Instead, I’ll bite the bullet and just code an interface for setting them up.[ref]In situations where a host exposes an interface for me, I’ll just use theirs instead of rolling my own.[/ref] If I absolutely have to hard-code credentials, I do so with a [cci]_local.conf[/cci] file that’s ingored globally.
I also hand-check every single diff before I commit changes to be sure I haven’t accidentally committed a file or that my command-line tools haven’t created a swap/change/save/tmp version of the [cci]_local.conf[/cci] file that’s now in the list of files to be committed.
Additionally, this lesson also taught me never to use the [cci]-a[/cci] flag when preparing a Git commit – always inspect the list of changed/new files to be sure you know exactly what’s going into a repository. Once it’s there, it’s there for good.