Live data from Hacker News

The Apple goto fail vulnerability: lessons learned (2014)

dwheeler.com

31–40 of 42 posts

Re: The Apple goto fail vulnerability: lessons learned (2014)

#31
post #9

Earlier quoted context omitted.

Code Formating tools can help avoid this too.

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.

That's basically the idea behind lisp (until you get into macros).

Re: The Apple goto fail vulnerability: lessons learned (2014)

#32

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.

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.

>They add visual noise.

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".

How about "dither"?

Re: The Apple goto fail vulnerability: lessons learned (2014)

#33
post #29

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.

Re: The Apple goto fail vulnerability: lessons learned (2014)

#34

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.

For as long at I live I'll never understand why why there wasn't a test suit to make sure that module and especially THAT module worked correctly.

Changes were made to that module without tests being run and then it was put into production code.

Re: The Apple goto fail vulnerability: lessons learned (2014)

#35
> 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.

Re: The Apple goto fail vulnerability: lessons learned (2014)

#36
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".

Re: The Apple goto fail vulnerability: lessons learned (2014)

#37
post #21

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 vuln…

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. [1] https://news.ycombinator.com/item?id=25726068 [2] https://habrahabr.ru…

This was obviously a merge error.

Re: The Apple goto fail vulnerability: lessons learned (2014)

#38
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.

Re: The Apple goto fail vulnerability: lessons learned (2014)

#39

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.

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.

That is probably why styles like

  if (cond) {
    // statement
  } else {
    // statement
  }

existed. Allow you to quote everything while not waste so much vertical space.

Re: The Apple goto fail vulnerability: lessons learned (2014)

#40
post #36

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 prod…

But what tool verifies that the code is MISRA compliant? Then you’re just stating “my code is MISRA compliant according to tool W version a.b.c” ;)
Post reply on HN