login
Search
"I think people are placing too much blame on valgrind. valgrind doesn't tell you 'Delete this line of code.' It says 'You are using uninitialized memory here.' The correct fix is to initialize the memory, not delete the line of code. It's not about trusting or not trusting the tool; it's about responding correctly."
The real problem is the
The real problem is the person serving as Debian maintainer of the openssl package. Only a bloody amateur would think that removing a function call would not change the meaning of a program. What will he do next? Put an #if 0 / #endif bracket around the contents of the main() function, so that there will no longer be valgrind hits?
It continues to boggle my mind that this person is permitted to continue in that role.
It was known for a fact that
It was known for a fact that OpenSSL was deliberately using uninitialized stack data as one of its entropy sources. If you want to remove uninitialized stack data from the entropy pool, you delete a function call -- because feeding a bunch of zeroes into the entropy pool doesn't make sense.
Furthermore, even if he had zeroed out the buffer at the same place, he would still have introduced the same bug. I believe mr. Ted Unangst is trolling without a clue here.
The actual problem is that given maintainer didn't look far enough to notice that the buffer was passed in as a function argument, and the uninitialized pointer came from elsewhere.
Re: It was known for a fact that
So, what you are really saying is that the Debian maintainer was a bloody moron who decided to poke around the code of the central security library without bothering to look further than his nose to check ramifications of the code he was modifying, or atleast having the good sense to ask someone who knew the code better.
When you are not 100% sure what some code in a sensitive library does, you leave it the fuck alone!
I fully agree with the original commenter above, allowing this person to continue maintaining such a crucial piece of infrastructure is inexusable.
Why are you even responding
Why are you even responding to me? You completely missed the point of what I was saying. I am not defending the Debian developer's decision, I am addressing Ted Unangst's idea of "responding correctly". His suggestion of seeding the random number generator with a zeroed-out buffer would not have had a better result.
What's worse, he knows that there was a security problem in the given piece of code, yet is still proposing an equally broken solution AFTER the fact? The only conclusion I can draw is that he is more clueless than the Debian developer who wrote the original patch.
You are correct
You are correct, I misread your post as defending the Debian developer. We are in agreement that what the Debian developer did was boneheaded. I also agree that OpenBSD developer's proposal taken at face value is equally boneheaded, but he may have been speaking in generalities (which is no excuse if he actually acts based on those generalities).
In either case, the point stands: when you don't fully understand some sensitive code, the "correct response" is to not mess with it!