Re: Test-Driven Development
Actually I can understand the lack of a test case for this - as you'd have to write the exploit as the test.
What I can't understand is the following:
1) why the compiler, or code coverage tool, didn't flag the final check as unreachable code, or - if it did - why didn't anyone notice how important the unreachable code was?
2) why it wasn't noticed on visual inspection - even with the apparent failure of correct indentation (which should have been automatic), surely it's reasonably clear there's a duplicated line?
3) why the programmer chose to write the code in this way? I'm not a programmer any more, as apparently I'm 'too expensive' and am now only allowed to 'create' using MS-Office products --- but this stuff is rubbish, who writes it? For a start, the 'fail' label is simply misleading as this code is concerned with resource release. There's at least three ways of writing this method in a more elegant way. I might have used non-evaluating conjunctions or nested if statements, but I can guarantee that whatever I did the return code would never have been set to success before all the conditions had been met. In fact even using reasonable logging in this code would almost have forced the author to write it in the correct way as each failure condition would have to be tested:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
would probably have to be something like
err = SSLHashSHA1.update(&hashCtx, &signedParams
if(err != 0) { logger.log("failed at signed parameter check"); goto fail}
In other words, the principle failure here is conflation of the test with the assignment. We do not have to hand-optimize code anymore. I don't know why programmers even try to do it: the most important thing is correctness, then comprehensibility. Everything else, compactness, hell, even performance, comes a very long way behind those two attributes.
Biting the hand that feeds IT
