The Apple goto fail vulnerability: lessons learned (2014) (opens in new tab)

Hi, I'm the author of the referenced article. Thanks for pointing to it!

However, can you change HN thread to the article title, which is: "The Apple goto fail vulnerability: lessons learned"?

I never used the term "backdoor" in the entire article, and I certainly never claimed that this was an intentional backdoor or that it looked just like a backdoor. I said, "The Apple goto fail vulnerability was a dangerous vulnerability that should have been found by Apple." - but I never said it was intentional. I personally doubt it was intentional (it's possible, but I have no specific evidence suggesting it).

While I'm here... ask me anything (AMA)!

For as long as I live, I’ll never understand style guides that permit omitting brackets around a single line following an if statement (or for, while, etc), nor code formatters that dont automatically insert them.

Meh, I worked on C at Apple and that programming style was idiomatic there. There’s nothing malicious about it, it was almost certainly a diff tool or merge error that resulted in the duplicated line.

One thing that was weird about our merges was that we always had way too many branches in flight for the current OS X, the last OS X, the next OS X beta, iOS, the next iOS, and the Windows iTunes stuff.

Even though we had a small team inside our division dedicated to releases, it's almost guaranteed there will be merge issues when managing that many forks of the same SVN or git repo.

One of the ideas to make this error visible is to forbid misleading indentation (section 3.5). It would be cool if the IDE can show this goof straight away..

> Arie van Deursen argues that “code formatting is a security feature” and that indentation “white space is a security concern. The correct indentation immediately shows something fishy is going on...” [vanDeursen2014]. Arie van Deursen also argues that code formatting should be done by tools, not by hand, and shows that clearly this code was not routinely formatted automatically.

Praise then for languages with significant white space? Using a formatter tool to add the white space and a lint rule in your compiler to catch when it's not done is a bandaid for something that should be encoded into the language in my opinion. Leaving this stuff optional to enforce only eats up productivity for no decent upside.

Title of this story is heavily editorialized. The article mentions nothing about the backdoor.

>The problem with ‘goto’ is that it allows developers to create ‘flow’ in code that is unnatural... and that’s bad because developers should always strive to make code easy to read.

Those aren't mutually exclusive

The code written in my company must follow the MISRA rules. Among the others, there is a rules that requires branches to have code blocks, and another one that prohibits the use of goto.

Yes, compilers have flags, coding standards can achieve the same results. The point is that this stuff is non standard, not everybody uses GCC or Clang. Stating "this code is MISRA compliant" is stronger that "this code does not produce compile warnings with the flags x, y, z on compiler W version a.b.c".

I'm afraid the only working solution to prevent this type of errors is to switch to a programming language that requires you to use braces around if statement body. Static analyser is an optional tool, with output that sometimes points out to perfectly correct code, thus making it more a nuisance then a helping tool in the eyes of a time-constrained programmer.