Apple's SSL/TLS bug
141–150 of 295 posts
Re: Apple's SSL/TLS bug
#142Unfortunately OSX does not appear patched even in the latest developer center 10.9.2 build (13C62). Tested in both Safari and OS-distributed curl. Chrome/Firefox of course is still fine since it uses the NSS stuff, but plenty of OS services use the OS crypto. (I'm violating NDA by commenting on pre-release Apple stuff, of course.) Windows or ubuntu bootcamp until they fix this, I think.
Re: Apple's SSL/TLS bug
#143If blocks without curly braces ಠ_ಠ
I cringe whenever I hear people advocating that it's okay to avoid braces with single-statement conditionals/loops/etc. This is a perfect example of just how bad that suggestion is, and just how disastrous it can be. It's totally worth typing a few extra characters here and there to basically avoid these kind of situations completely.
if (something) do_something();
Instead of: if (something)
do_something();
So it's much less likely that I'll confuse indentation with a block scope.Re: Apple's SSL/TLS bug
#144Earlier quoted context omitted.
Exactly this This also applies to the "JS without ;" crowd. You may think you're too good to know all the rules of ; or you can just don't think about it, and worry about other things instead, like your code.
I hate omitting braces, but Javascript semicolon omission is a totally different argument. It's easy to show simple cases where omitting braces causes problems. It's actually quite difficult and artificial to find cases where (especially with "use strict") semicolons confer any benefit at all, and in some cases they make things worse (e.g. multi-line variable declarations). Also, "correct" use of semicolons in Javasc…
IIFEs are the most common source of semicolon problems:
for(i = 0; i
A less common sort of pattern that I still use pretty often as a DRY measure: init()
[x, y, z].forEach(function(a){
if(a.length > 5) {
process(a)
}
})
This is clean and readable, and without semicolons it's completely wrong.Now sure, you can prepend semicolons to these specific cases, and that will work. Here's why I dislike that:
1. Those leading semicolons look weird. To the uninitiated, it looks like a typo, and that's a significant hazard if anyone else is going to touch your code.
2. While there are only a handful of special rules like this to remember, there's only one rule to remember if you don't rely on ASI.
Re: Apple's SSL/TLS bug
#145Dijkstra always contended GOTOs were harmful! In all seriousness it's unfortunate the C family of languages even allow this kind of bug - we've all been bitten by it at one time or another.
> Dijkstra always contended GOTOs were harmful! - The bug here has nothing to do with GOTO. - Dijkstra said a lot of stupid things, this is one of them. Parsimonious use of GOTO is fine and sometimes leads to clearer code (exiting deeply nested conditions for example). - Another stupid thing that Dijkstra said is that anyone who started by learning BASIC has their brain corrupted forever, which is total nonsense (I b…
Re: Apple's SSL/TLS bug
#146Earlier quoted context omitted.
MITM of any SSL connection in Safari and other system apps, and they couldn't even bother to have an OS X patch ready at the same time as the disclosure for iOS? I think anyone relying on the security of OS X is going to have to seriously rethink their OS choice after this.
> I think anyone relying on the security of OS X is going to have to seriously rethink their OS choice after this. 10.7.3 logging FileFault (that was a typo, but I think I'll keep it) passwords in plain text might have been a subtle hint in that direction.
Re: Apple's SSL/TLS bug
#147If blocks without curly braces ಠ_ಠ
and goto statements everywhere :S
This is not spaghetti code or what Dijkstra talked against.
It's one of the two things one hears novices: that gotos are to always be avoided (because they heard that they are bad), and that we should write stuff in assembly (cause they heard that it's fast).
Re: Apple's SSL/TLS bug
#148Unfortunately OSX does not appear patched even in the latest developer center 10.9.2 build (13C62). Tested in both Safari and OS-distributed curl. Chrome/Firefox of course is still fine since it uses the NSS stuff, but plenty of OS services use the OS crypto. (I'm violating NDA by commenting on pre-release Apple stuff, of course.) Windows or ubuntu bootcamp until they fix this, I think.
MITM of any SSL connection in Safari and other system apps, and they couldn't even bother to have an OS X patch ready at the same time as the disclosure for iOS? I think anyone relying on the security of OS X is going to have to seriously rethink their OS choice after this.
It's mainly an SSH and RDP terminal anyway.
OSX quality and QA is extremely bad.
Re: Apple's SSL/TLS bug
#149Dijkstra always contended GOTOs were harmful! In all seriousness it's unfortunate the C family of languages even allow this kind of bug - we've all been bitten by it at one time or another.
First, the problem here is totally different than the goto, it's the uncoditional execution of something that was meant to be in a if clause. It could have been anything, even without goto, and have the same problem.
Second, this is not the kind of use of goto that Dijkstra warned about. This is perfectly fine, and widely used from the best programmers.
The error is in the lack of an if guard.
Re: Apple's SSL/TLS bug
#150Earlier quoted context omitted.
My gut says the probability of a random typo executing without raising an error or exception is rather low. The probability of it doing so in a way that well aligns with the interests of nation states, large corporations, and/or criminal enterprise is even lower. This might explain DROPOUTJEEP particularly considering how much more efficient it is than breaking messages after they are encrypted. http://mobile.eweek.c…
Sure, this aligns with interests, but the bug's existence is predicated on the entire code base being written with substandard style rules and no static analysis or tests , which suggests to me that incompetence got here first.