Live data from Hacker News

Apple's SSL/TLS bug

imperialviolet.org

291–295 of 295 posts

Re: Apple's SSL/TLS bug

#291
post #104

Earlier quoted context omitted.

Sure, but at least you have a say there.

If you need to say something to make it secure then wouldn't it also be compromised by default? Security is not a Boolean. A better question is, which OS is more secure OOTB for a given user.

For some users, none of them. Some users, no matter what, demand password as their password.

Re: Apple's SSL/TLS bug

#292

Earlier quoted context omitted.

It was likely someone subverting the process for reasons of urgency, for good intentions or malice. Simple static analysis or unit tests would have caught this.

Exactly! So strange apple didnt have a testcase for this.

Yea, and we're supposed to believe that no QA person did any testing on this either.

Re: Apple's SSL/TLS bug

#293
post #287

Earlier quoted context omitted.

> You cannot sue a programmer for writing a bug in software ... Of course you can. > It is the company's responsibility ... Not if the programmer was hired for his independent expertise rather than to be told what to do, and how to do it, by higher-ups. That's a a common arrangement in small companies. > There are so many bugs in software, that this would be a terrible standard to set, and no developer would be safe.…

> Not if the programmer was hired for his independent expertise rather than be told what to do, and how to do it, by higher-ups. That's a a common arrangement in small companies. 1. That does not excuse software from a proper code review process, in fact any reasonable software company would probably see this as even more of a reason to code review the code. If I knew that a software company doesn't properly review c…

>> Not if the programmer was hired for his independent expertise rather than be told what to do, and how to do it, by higher-ups. That's a a common arrangement in small companies.

> 1. That does not excuse software from a proper code review process, in fact any reasonable software company ...

You changed the subject. The original subject was whether a programmer could be held accountable for a bug in a computer program. The answer is yes, under civil law, that can happen.

There are companies whose computer science departments consist of one person, which was my example, and in such a case, there is no company-wide software review process, because -- as I already said -- the computer science department consists of one person working alone.

Feel free to change the subject if you want.

Re: Apple's SSL/TLS bug

#294

Can't wait for Apple to patch this bug? Downgrade to 10.8.5 ... The answer here, folks, is don't update until all the bugs have been found and fixed. Apple's golden days of OS updates was back in 10.6, when they spent most of the time just fixing bugs rather than adding new features. Every OS update since has had as many bugs as it fixed, though overall things were getting better. It's the old Wait-until-SP1 advice.…

> The answer here, folks, is don't update until all the bugs have been found and fixed. How can you ever be sure of this? And also I can almost guarantee that there is no non-trivial software that is bug free. As a programmer the only way you can guarantee bug-free code is to not program at all. So if you follow this advice, you will never update at all, which in my opinion is bad because the benefits of an update ou…

I was being facetious in that one line. I never expect "all" the bugs to be fixed, but it's equally true that if you wait 8 months, you'll know better what you're upgrading /to/. In this case, 10.9 had the bug, 10.8 did not. It's usually the case that as new features are added, it's much more likely that you've added new bugs. Whereas in slightly older code, you might be "out of date" but at least you know where the bugs are, generally, by watching what changes in newer releases and back-port as necessary. And as I think I've said elsewhere, if code is updated frequently, this advice might change -- so long as you're running a stable channel, you can both get new updates and enjoy tested code.

Re: Apple's SSL/TLS bug

#295
post #239

Earlier quoted context omitted.

It helped us realize how easy it would be to test for this, and that Apple isn't.

I question your code comprehension. This is not easy to test for at all, and Chrome doesn't do it either. Do you understand how to exploit this issue?

Static analysis would have caught this immediately. It caused unreachable code that the compiler even recognized and optimized away.

You're saying Google Chrome doesn't test that an ephemeral key is actually signed by the cert's private key? If that's the case, that's completely unacceptable because it's the whole point of the protocol.

Post reply on HN