dwheeler 12 days ago []
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)!
reply
dang 12 days ago []
Fixed now. Thanks!
(Submitted title was "The Most Backdoor-Looking Bug Ive Ever Seen: Apple's goto fail bug (2014)". Submitters: please don't do thatit'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.)
reply
dwheeler 12 days ago []
Thanks! And while I'm here, THANK YOU for all the thankless work you do. MANY people, including me, appreciate it!
reply
MrXOR 12 days ago []
Excuse me.
reply
dwheeler 12 days ago []
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.
reply
MrXOR 12 days ago []
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/206900reply
dwheeler 12 days ago []
> ... your excellent essay (with many useful hyperlinks) about it.
Thank you so much!
reply
olliej 12 days ago []
This was obviously a merge error.
reply
dwheeler 6 days ago []
I think that's very likely, but I've never seen a post mortum from Apple where they track down what happened.
I wish they would be more open about what happened. Mistakes happen. It's better for the industry if we can all learn from them.
reply
pansa2 12 days ago []
The OP has re-used the title of an unrelated article posted a few days ago, for some reason:
https://news.ycombinator.com/item?id=25726068reply
gigatexal 12 days ago []
Flagged in hopes the title gets changed
reply
bobbylarrybobby 12 days ago []
For as long as I live, Ill 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.
reply
efwfwef 12 days ago []
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.
reply
xxpor 12 days ago []
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.
reply
Gibbon1 12 days ago []
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.
reply
kevin_thibedeau 12 days ago []
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.
reply
coldtea 12 days ago []
>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"?
reply
tpush 12 days ago []
IMO you get accustomed to single statement-braces very quick and they leave less room for errors.
reply
mmis1000 11 days ago []
That is probably why styles like
if (cond) {
// statement
} else {
// statement
}
existed. Allow you to quote everything while not waste so much vertical space.
reply
efwfwef 12 days ago []
and remove bugs
reply
lucasyvas 12 days ago []
I agree - it should be a compile or runtime error.
reply
umvi 12 days ago []
Well if you compile with `-Werror -Wall` (and you should), it would throw in error in GCC 6+:
https://developers.redhat.com/blog/2016/02/26/gcc-6-wmislead...
reply
jimbob45 12 days ago []
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 dont think thats truly practical with the preprocessor.
reply
int_19h 8 days ago []
What's the practical difference between:
if (foo)
bar;
else
baz;
and:
if (foo) {
bar;
} else {
baz;
}
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.
reply
efwfwef 12 days ago []
Show Posts
.com/?feed=aHR0cHM6Ly9mZWVkcy5jYXB0aXZhdGUuZm0vY29iYmxlcnN0b21lLw%3D%3D&hl=en-GB
