Hi,
When debbuging applications that make use of openssl using
valgrind, it can show alot of warnings about doing a conditional
jump based on an unitialised value. Those unitialised values are
generated in the random number generator. It's adding an
unintialiased buffer to the pool.
The code in question that has the problem are the following 2
pieces of code in crypto/rand/md_rand.c:
247:
MD_Update(&m,buf,j);
467:
#ifndef PURIFY
MD_Update(&m,buf,j); /* purify complains */
#endif
Because of the way valgrind works (and has to work), the place
where the unitialised value is first used, and the place were the
error is reported can be totaly different and it can be rather
hard to find what the problem is.
Valgrind has mechanismes to suppress error messages. One of them
is based on the stack trace, if it happens in func1, called by
func2, called by func3, ... you can tell it to ignore it. This
doesn't really work in case of openssl. The place where it
reports the error message ussually doesn't have any openssl
functions in the stack trace.
An alternative mechanism is to make changes to the source code
that can tell valgrind to ignore the unitialised values and
pretend that they are initialiased. This changes the library in
such a way that valgrind can detect it when it's running, but the
library can be used without valgrind too. I'm not really in
favour of changes like that.
What I currently see as best option is to actually comment out
those 2 lines of code. But I have no idea what effect this
really has on the RNG. The only effect I see is that the pool
might receive less entropy. But on the other hand, I'm not even
sure how much entropy some unitialised data has.
What do you people think about removing those 2 lines of code?
Kurt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
