Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Apple and security: 5 deadly development sins

Andrew C Oliver | March 4, 2014
If Apple carries on with its many programming misdeeds, it will soon see a breakdown in its shiny, new security

Recently, Apple decided to replace open source OpenSSL with its own libsecurity_ssl. In doing so, Apple went from a large community to a small community with poor development practices.

Reportedly, the company made the move due to OpenSSL not having a "stable API," meaning that when Apple distributed security patches to OpenSSL, applications dependent on it would break. It had other options, such as creating a wrapper and asking people to use that instead; backporting fixes to old versions (à la Red Hat); or working with the community to stabilize the API. In my past dealings with Apple, however, I've noticed it doesn't play so nice with others unless it makes all the rules and serves as decider. I have a feeling other options were moot before it made their own security library.

Which brings us to Apple's first deadly sin: arrogance. Arrogance is a common bug in software developer personalities. It's fine if it makes you no fun at parties or wins you an InfoWorld column, but it isn't fine if it leaks into your code. Humble developers assume code can be broken and can live with attempts to prove that even if they wrote it. The code is proven bad — not your fragile ego. The first thing I teach green developers is to assume their favorite theory is wrong and to seek to disprove it rather than prove it. People who try to prove themselves right are prone to confirmation bias and looping.

This brings us to Apple's second deadly sin: I can't find the automated tests for libsecurity_ssl. According to a poster on Hacker News, there are a couple dozen tests (a bit light for this sort of thing), but I couldn't find them.

On the other hand, I found a comprehensive suite of tests for OpenSSL. In fact, maybe Apple should have run a version of this on its code since a casual glance would have caught it — which means Apple doesn't actually run automated tests on check-ins.

We're not talking a full agile process; we're talking basic principles. I often get comments from people who dispute the nature of a "unit" or what an integration test should be, but surely we can all agree that you should have an automated test before release as to whether your SSL library validates SSL certs?

Possibly related to the first deadly sin is Apple's general lack of collaboration. We know best, fork first, rewrite first — then maybe we let the cool kids join us if they are worthy. Sometimes this has turned out well and we get KHTML turning into WebKit (which Google has in turn forked -—but that's for another post). This time, it cost Apple customers and users. For security, having the larger community is critical; collaborating rather than keeping your failures secret until you fix them is key. This culture of secrecy and arrogance has been written about before and will bite Apple again.

 

1  2  Next Page 

Sign up for Computerworld eNewsletters.