Amazing example. Blindly doing anything because of Valgrind is bad, but I think a better rule might be "Don't comment out lines you don't understand in a standard cryptography package and then distribute it to users without warning". I don't think a mere "mention of the need for caution" could have saved anyone here. Handcuffs and a straightjacket on the Debian developer might have been required in this case.
This link covers it well:
What can we learn from this? Firstly, vendors should not be
fixing problems (or, really, anything) in open source
packages by patching them locally – they should contribute
their patches upstream to the package maintainers. Had
Debian done this in this case, we (the OpenSSL Team) would
have fallen about laughing, and once we had got our breath
back, told them what a terrible idea this was. But no, it
seems that every vendor wants to “add value” by getting in
between the user of the software and its author.
Secondly, if you are going to fix bugs, then you should
install this maxim of mine firmly in your head: never fix a
bug you don’t understand. I’m not sure I’ve ever put that
in writing before, but anyone who’s worked with me will
have heard me say it multiple times.
"...we (the OpenSSL Team) would have fallen about laughing..."
Note this attitude of derision and arrogance. It's interesting that this was before the quality of OpenSSL code became common knowledge, heartbleed and finally the major work of LibreSSL. I'm not sure if I'd just really like this kind attitude to be a good indicator of trouble coming or it really is so.
Valgrind's diagnostic here was more or less correct. Using uninitialized memory as an entropy source is pretty useless. Uninitialized memory isn't filled with randomness, it's filled with stuff that's not guaranteed. This makes it harder to predict, but if an attack depended on it, you can bet that a smart attacker will figure out what the uninitialized memory would actually contain in your case. (Edit: I think I should clarify here. Adding uninitialized memory to your entropy pool doesn't hurt, as any good CSPRNG will be robust to adding data to the pool that's known to an attacker. It just doesn't help very much, because it's not very random.)
The Valgrind diagnostic was a good one and it was worth fixing. The problem wasn't Valgrind, but rather the fact that the fix inadvertently broke the code in a way that was difficult to detect.
For a poor analogy, imagine that you ask for an assessment of the structural integrity of a building. The assessment comes back saying that some supports are weak and should be replaced. Based on this report, you replace the supports. However, instead of replacing just the weak supports, you replace all of them, and you replace them with supports that look solid but are completely rotten. Then the building falls down. This is not the fault of the report, but rather the fault of the response to it.
https://www.schneier.com/blog/archives/2008/05/random_number...