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).
(Submitted title was "The Most Backdoor-Looking Bug I’ve Ever Seen: Apple's goto fail bug (2014)". Submitters: please don't do that—it's against the site guidelines, which ask: "Please use the original title, unless it is misleading or linkbait; don't editorialize." We eventually take submission privileges away for breaking that rule, so please follow it.)
No problem! Thanks for pointing people to the article, I write articles with the hope that someone will read them :-).
That article is part of a series of articles called "Learning from Disaster": https://dwheeler.com/essays/learning-from-disaster.html
I think we can learn from the past, and sometimes learning a story & working to gain lessons learned from it can really help.
Excuse me for changing the title of your essay. I should not do that.
The title was just my opinion. Some days ago, I read the excellent newsletter [1] of Filippo Valsorda about a Telegram's bug [2]. Yesterday, I googled for bugdoors and read about them and found this Apple's bug and your excellent essay (with many useful hyperlinks) about it.
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.
I'm so glad that modern languages are opinionated and have default formaters that come with them. Jumping from one C codebase to another is really a nightmare, especially if you want to review code. That's a security issue in my book, as you end up with more reading complexity.
I'm convinced the GNU style is just for gatekeeping at this point. You REALLY have to want to work on a codebase with that after reading anything remotely Linux inspired.
They add visual noise. The grammar of C is not the same as the grammar of it's offshoots and block statements aren't part of control structures. Moreover, GCC warns about extra statements with the same indentation level with -Wall on.
Which is a good thing, since it prevents errors such as this one. Extra verbosity with mandatory braces is noise (to the degree that without it, the compiler could still infer what we mean), but some degree of verbosity is a good thing, as it helps make patterns in the code more evident.
In which case we might want to call it a more fitting error than the dismissing "noise".
The latter has one extra line, which is hardly bloat. It also has the braces, of course, but the upside of this style is that it's clear where the compound statement begins (it's the line that doesn't start with a brace!), and where it continues.
harder to follow? In what sense? Because in my book the fact that you can write both the line with braces and without make it much harder to think about, whereas in most other languages I don't need to think about it because there's only one way to write that.
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..
However, for some reason, while GCC puts it under -Wall, Clang (which Apple uses) doesn't enable it even with -Wall -Wextra; you have to manually add -Wmisleading-indentation. It's also not enabled by the default Xcode template.
At some point we should juat switch to editing abstract syntax trees instead of raw text. Then formatting is irrelevant, the structure is always clear, and each developer can choose their own way to view the code.
True, though you'd have to run the formatting tool with different rules on both checkout and commit for developers to be able to use their own preferred formats. Also keeping the syntax tree would make non-textual displays and visualizations easier.
> 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.
>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.
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.
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)!