Saturday, 1 March 2014

Lessons from Apple's SSL Bug

There’s a summary here of Apple’s recent SSL bug in iOS.

This sort of subtle bug deep in the code is a nightmare. I believe that it's just a mistake and I feel very bad for whoever might have slipped in an editor and created it.

Here's a stripped down that code with the same issue:

extern int f();
int g() {
int ret = 1;
  goto out;
ret = f();
out:
return ret;
}


If I compile with -Wall (enable all warnings), neither GCC 4.8.2 or Clang 3.3 from Xcode make a peep about the dead code. That's surprising to me. A better warning could have stopped this but perhaps the false positive rate is too high over real codebases?

I fired up AppCode, the world’s best Objective-C IDE, which happens to also support C. I added the code snippet above, and it instantly and correctly highlighted the line “ret = f();” as unreachable code.

Lessons I take from this:

  • Use a state-of-the-art IDE that has excellent real-time code analysis tools. Don’t ignore the warnings it gives unless you have a really good reason for doing so. And even then use a error suppression technique.
  • Don’t ignore compiler warnings. Oh right, I already wrote that. It’s important, you see. Start ignoring warnings, and then when a really important one appears you won’t notice because it will be just one of dozens of warnings that you conditioned yourself to ignore.
  • Before committing code, run static analysis tools on it. Fix the issues detected.
  • If possible, have a formal code review on any code you’ve changed that is dealing with security, memory management, or threading.

There is much data and research that shows that these techniques lead to much higher quality software.

No comments:

Post a Comment

Note: only a member of this blog may post a comment.