Skip to content

Protecting source code

As I mentioned on the missing iDeveloper.tv Live episode, one of the consequences of the Gawker hack was that their source code for their internal software was leaked into the Internet. I doubt any of my readers would want that to happen to their code, so I’m going to share the details of how I protect my clients’ code when I’m working. Maybe some of this will work for you.

In the office, I work at a desktop iMac. This has an external time machine backup disk and a DropBox for off-site storage. However, client code does _not_ go onto the DropBox. Instead I keep a separate, encrypted sparse disk image for each project I’m working on. The password for each is different. As well as protecting against snooping, this helps stop cross-contamination. I rarely have two such images mounted at once. Note that it’s not just source that goes into these images: build products, notes, Instruments traces, and images all go into the encrypted containers.

Obviously that means a lot of passwords, and no I can’t remember them all. I use a keychain. It locks automatically when not in use, and has a passphrase that’s different from my login passphrase.

The devices I test on are all encrypted where available (if a client needs me to test on an iPhone 3G, then I can, but it isn’t encrypted). They are passphrase locked, set to require passphrase immediately. And I NEVER take them away from the desk before deleting any developer builds, unless I need to do something special like a real-world location services test.

I rarely do coding work on the laptop, but when I do I copy the appropriate encrypted image onto it. The laptop additionally has FileVault configured, though I’m evaluating full-disk encryption options. Keychain configuration as above, additionally with a password required on wake from sleep or screensaver, and a firmware password.

For pushing work back to the clients, most clients use github or bitbucket which offer SSL-encrypted connections to the repositories. Personally, I have a self-run repo host available over HTTPS or SSH, but will probably move that to a github-like service because life’s too short. Their security policy seems acceptable to me.

{ 2 } Comments

  1. Oliver | December 15, 2010 at 9:17 pm | Permalink

    What sort of impact does this have on your productivity? Is all that encrypting not slowing things down terribly? And what would happen if you lost your passwords or there was a keychain issue? And is it strictly necessary to go to such a great length? Should we all be doing this?

  2. Graham | January 3, 2011 at 11:49 am | Permalink

    @Oliver: it’s not a performance problem at all. It takes a few minutes to set up per project, and then I have to double-click a DMG before I do any work. Assuming I lost my passwords, I could recover the data from the upstream repository.

{ 3 } Trackbacks

  1. [...] This post was mentioned on Twitter by Graham Lee, Steve Billingsgate. Steve Billingsgate said: RT @iamleeg: Protecting source code: http://blog.securemacprogramming.com/2010/12/protecting-source-code/ [...]

  2. [...] my own environment as an example, I go to great lengths to protect my clients’ source code (I’m in app security). I also use WPA2 on the router and change the password every so often [...]

  3. [...] my exclusive surroundings as an example, I go to great lengths to protect my clients’ supply code (I’m in app security). I also use WPA2 near to the router and alter the password just about [...]