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

'Heartbleed' contributor denies he inserted it deliberately

smh.com.au

Post reply on HN
Print view View original

51–60 of 86 posts

Re: 'Heartbleed' contributor denies he inserted it deliberately

#51

Post by danielweber »

protomyth wrote: post #32
weavie wrote: post #9

I can't imagine what this guy must be feeling right now. I find it embarrassing enough when I am outed in my small team for producing a bug that makes it into production. To be known around the entire internet to have caused the largest security bug in recent times must be quite a slammer. I really hope it doesn't affect his career..

I'm actually more worried that this will result in a civil lawsuit from one of the affected companies. In an ideal world[1], it would get thrown out immediately, but I'm a bit worried. That would have a heck of a chilling affect. 1) and a simple reading of the license

Is it 'rayiner who tells us to always have the disclaimer for liability in our licenses? Whoever it is, this is why.

I think any company that is damaged by this should get all their money back, all $0 of it.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#52

Post by mikeash »

anextio wrote: post #26
sillysaurus3 wrote: post #17

Earlier quoted context omitted.

Refcounting unfortunately fails for GC because it can't handle cyclic dependencies, e.g. object A references object B which references object A, now neither object will ever be freed even if nothing else references A or B.

Objective-C programmers have been using refcounting at scale for at least 2 decades. No problems here.

I wouldn't say "no problems here" at all. Memory management errors are extremely common in Objective-C code. This is true even with ARC. The problems can be solved, but they are certainly there.

The question of cycles is even more pertinent with ARC, because it's easy to get used to letting the compiler do everything for you, and it's easy to miss an occasional leak of a cyclic object graph.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#53

Post by pornel »

sillysaurus3 wrote: post #17
pornel wrote: post #15

Earlier quoted context omitted.

C vs GC is a false dichotomy. There can be safer-than-C languages that don't use GC, e.g. you don't need GC for array bounds checking. You can use reference counting for more deterministic garbage collection.

Refcounting unfortunately fails for GC because it can't handle cyclic dependencies, e.g. object A references object B which references object A, now neither object will ever be freed even if nothing else references A or B.

You don't need to automatically solve all the problems to get a safer language than C/C++.

I don't think cyclic object graphs are needed to, say, respond to a TLS heartbeat without out-of-bounds reads.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#54

Post by mikeash »

weavie wrote: post #9

I can't imagine what this guy must be feeling right now. I find it embarrassing enough when I am outed in my small team for producing a bug that makes it into production. To be known around the entire internet to have caused the largest security bug in recent times must be quite a slammer. I really hope it doesn't affect his career..

I wouldn't be surprised if it was good for his career in the long run. Smart people will know that bugs like this can happen to anyone, and he'll have huge name recognition. As long as he's humble about it, "Yeah, I'm the guy who broke OpenSSL. Man, that sucked." I could see it being a big plus in interviews after a year or two.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#55

Post by protomyth »

danielweber wrote: post #51
protomyth wrote: post #32

Earlier quoted context omitted.

I'm actually more worried that this will result in a civil lawsuit from one of the affected companies. In an ideal world[1], it would get thrown out immediately, but I'm a bit worried. That would have a heck of a chilling affect. 1) and a simple reading of the license

Is it 'rayiner who tells us to always have the disclaimer for liability in our licenses? Whoever it is, this is why. I think any company that is damaged by this should get all their money back, all $0 of it.

My only worry is some nasty lawyer will figure out a way around the disclaimer. I am hoping not and that it has been well established, but the courts are often a bit insane.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#56

Post by ajanuary »

fournm wrote: post #45
ajanuary wrote: post #38

Earlier quoted context omitted.

I don't know how Coverity works - is it possible that surrounding it with more complex code will cause it to miss the bug because it doesn't have enough information to not constantly raise false positives?

I'm not familiar with Coverity, but Sonar (for the Java world) is very similar in concept and will fail to detect things if there are enough issues before it in a file... Which I would HOPE is not the case here.

From my experience with static analysis tools it's very easy to write perfectly valid code that the tool doesn't like, so it wouldn't surprise me too much.

Of course, the argument can often be made that if it isn't clear enough for the tool to find, it's not clear enough for a person to understand quickly.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#57

Post by [deleted] »

notacoward wrote: post #29

Maybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" - which was always total BS from the day it was uttered. There's so much code out there, much of it highly specialized and even project-specific, that there are very few eyes looking at any particular piece of code, and not all eyes are connected to the greatest of brains. Most static code analyzers could h…

[deleted]

Re: 'Heartbleed' contributor denies he inserted it deliberately

#58

Post by svaha1728 »

fit2rule wrote: post #22

I just can't understand why such critical components as OpenSSL just don't use Code Coverage tools like Coverity to find such things as this? Testing, coverage certification, static analysis: this would have been caught if these tools were being used.

Does someone know the actual line of source where the error appears? The goto fail vulnerability was easy to catch with static analysis, but I haven't seen the actual lines of code for this one yet.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#59

Post by orblivion »

notacoward wrote: post #29

Maybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" - which was always total BS from the day it was uttered. There's so much code out there, much of it highly specialized and even project-specific, that there are very few eyes looking at any particular piece of code, and not all eyes are connected to the greatest of brains. Most static code analyzers could h…

> Most static code analyzers could have caught this particular bug

Does that mean nobody out there in the crypto world ran a static analyzer on OpenSSL in the last 2 years?

Re: 'Heartbleed' contributor denies he inserted it deliberately

#60

Post by talmand »

danielweber wrote: post #50
talmand wrote: post #24

Earlier quoted context omitted.

Unfortunately the tech industry seems to be in mob mode recently so I would think the chilling effect is already well underway. The fact that it has been suggested this was done intentionally before they know the whole story suggests this to me. Never mind the fact that the code was apparently reviewed, so I guess the reviewer would have been in on it as well. There are always people who prefer to play the blame game…

Part of me wants to see the team give the industry a big middle finger and quit the project, and now companies relying on it have to start spending money to keep it up instead of expecting it to be provided for free. If something is important to you, you should spend more resources than zero on it.

Does anyone know of a resource that shows who contributed and how?
Post reply on HN