Holes discovered in SSL certificate validation
Holes discovered in SSL certificate validation
Posted Nov 4, 2012 0:48 UTC (Sun) by pflugstad (subscriber, #224)In reply to: Holes discovered in SSL certificate validation by dvdeug
Parent article: Holes discovered in SSL certificate validation
But I've seen BAD Ada code - in safety serious situations. I've also seen really bad C & C++ code, where *attempting* to make the code strongly typed actually made the code worse. For example:
if ( classInstance == MANIFEST_CONSTANT )
the classInstance had an int operator(), so the compiler implicitly called that, and everything was fine. But because lint complained about different types, we ended up with:
if ( classInstance == (ClassType)MANIFEST_CONSTANT )
This instantiated a new instance of ClassType on the stack and then invoked operator==. This happened in 100's of places. And it even worked - until it ran out of stack. This was actually fairly painful to track down.
So - a fool with a (bad) tool is the main lesson here, but the tool is attempting to enforce strong typing, and the programmer blindly followed it.
I've seen similar stupidities in Ada code, so it doesn't save you any.
My point (I think) is that bad programmers easily trump strongly typed languages. It *might* lesson the problem - marginally. But in my experience, you OFTEN get the kind of stupidity I describe above, especially when development processes BLINDLY mandate running lint on your code and fixing all the warnings.
So I don't look to strongly typed languages as any kind of panacea. You can type silly things like converting a boolean to a 1 even there. You want good code: hire good, experienced programmers, and make them test their code.
On topic: I've tried to program against SSL's APIs. I totally agree with the article - they are HORRIFIC and I was just trying to do something trivial, nothing difficult like certificate verification.
