Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Apple goto fail vulnerability: lessons learned (2014)

dwheeler.com

Post reply on HN
Print view View original

21–30 of 42 posts

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

#21

Post by MrXOR »

dwheeler wrote: post #14

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/post/206900

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

#22

Post by MrXOR »

dang wrote: post #18
dwheeler wrote: post #14

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…

Fixed now. Thanks! (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.)

Excuse me.

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

#23

Post by nitrogen »

Forge36 wrote: post #9
netsharc wrote: post #2

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

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.

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

#24

Post by dwheeler »

MrXOR wrote: post #22
dang wrote: post #18

Earlier quoted context omitted.

Fixed now. Thanks! (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.)

Excuse me.

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.

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

#25

Post by dwheeler »

MrXOR wrote: post #21
dwheeler wrote: post #14

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…

> ... your excellent essay (with many useful hyperlinks) about it.

Thank you so much!

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

#26

Post by madeofpalk »

nitrogen wrote: post #23
Forge36 wrote: 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.

Well, when you edit with and require a code formatting tool as a part of your development lifecycle, you're basically there.

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

#27

Post by nitrogen »

madeofpalk wrote: post #26
nitrogen wrote: post #23

Earlier quoted context omitted.

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.

Well, when you edit with and require a code formatting tool as a part of your development lifecycle, you're basically there.

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.

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

#28

Post by efwfwef »

kevin_thibedeau wrote: post #10
bobbylarrybobby wrote: post #5

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.

and remove bugs

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

#29

Post by efwfwef »

bobbylarrybobby wrote: post #5

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.

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

#30

Post by efwfwef »

jimbob45 wrote: post #8
bobbylarrybobby wrote: post #5

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.

It can make code bloated and harder to follow. TBH it would be nice if someone made C with indent scoping instead of block scoping but I don’t think that’s truly practical with the preprocessor.

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.
Post reply on HN