Anyone got any thoughts on what the Debian project has been doing to OpenSSL

to have caused this in the first place?

yes, read the stuff posted earlier, it contains all relevant links. To

summarize, to silence a bogus valgrind warning, almost all seeding of

the PRNG used by openssl was removed. 
	-Otto

Mmmmmmm this isn't the first time I've heard of bogus reports from Valgrind.

How does one politely inform the Debian project to not trust it explicitly

and to human audit anything it flags?

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.
I've seen innocuous valgrind reports, but never wrong ones.  I also

saw a valgrind report ignored as innocuous because it didn't seem to

cause trouble, only to be the root cause of a problem that cost a

minimum of $50,000 to resolve later.

Yeah, using tools such as valgrind can help a lot, but the danger side

is that it will cause actions to be taken by people who do not

understand the code, just to silence valgrind. Since valgrind flags

the location of the use of uninialized mem, and--of course--not the

root cause, developers can easily be mislead and apply the wrong fix.

I think we have a clear demonstration of the danger of using a tool

without proper understanding of the code here. In addition, the vague

posts from both sides on openssl-dev mailing lists did not help too. 
	-Otto

This might be a good example. I'm working on a CLI which is rapidly

turning into a mini-shell. I'm not using readline, or other commonly

used things to gather input, for the purposes of my own learning and

keeping code portable I've elected to write my own functions.
Every time I make major changes, I run the program through valgrind.

Example results:
==10858==

==10858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from

1)

==10858== malloc/free: in use at exit: 48 bytes in 5 blocks.

==10858== malloc/free: 12 allocs, 7 frees, 4,182 bytes allocated.

==10858== For counts of detected errors, rerun with: -v

==10858== searching for pointers to 5 not-freed blocks.

==10858== checked 63,724 bytes.

==10858==

==10858== LEAK SUMMARY:

==10858==    definitely lost: 37 bytes in 3 blocks.

==10858==      possibly lost: 0 bytes in 0 blocks.

==10858==    still reachable: 11 bytes in 2 blocks.

==10858==         suppressed: 0 bytes in 0 blocks.

==10858== Use --leak-check=full to see details of leaked memory.
As you can see, my program is in its infancy and not much is allocated.

I have a leak due to some input stuff not freeing things that are

strdup()'ed (I know about this) and I have done a pretty good job of

being defensive so far.
If something I inherit from libc leaks or throws errors, I quickly know

and can explain it. "Its not my program, its stuff I used from xxx

function."
Valgrind is something that is (ideally) used as you go. If you screw up,

it will tell you. It should not be dismissed like trivial compiler

warnings, but it should also not invoke some kind of knee jerk

reaction. 
Its not exactly the world's best auditing tool for someone who is not

used to using it every step of the way. 
Taking something you are unfamiliar with and trying to correct whatever

valgrind complains about is asking for trouble beyond trivial warnings.
What amazes me about this whole mess is that at least 1/3 of the GNU

core utilities issue many complaints but they are ignored.

...
[ message continues ]

They probably have figured it out.  This is a pretty big screw-up--it

was in the tree since September 2006.  You don't do something this

bad and not learn from it =).
--

Travers Buda

And now the social engineering fallout from it as well with all

the 'new SSL certificate'-style phishing that was in place before

this event...
--

Monty Brandenberg, Software Engineer                               MCB, Inc.

mcbinc@panix.com                                             P.O. Box 426188

mcbinc@pobox.com                                   Cambridge, MA  02142-0021

617.864.6907