Hi,
> It certainly would, but Valgrind isn't the only analysis tool people
> might want to use. A runtime flag provides a means of obtaining accurate
> results with any tool.
Unfortunately, for am attacker it also provides a means of (possibly)
weakening your program's randomness behind your back, so IMO any way
to configure this behaviour at runtime is a potential security issue.
IMO it's better to tell people unable to ignore "bogus" warnings (or
make their analysis tool ignore them, e.g. via a suppressions file) to
use a special build option, like it's currently done.
In fact, I'd generally (i.e. not specifically for OpenSSL) wish
developers would invest more of their time into fixing bugs and/or
adding features rather than trying to get rid of the last "bogus"
warnings caused by some more or less obscure compiler or analysis
tool - that would also (need to) result in a healthier reaction to
such warnings by other developers and packagers: just assume that
the authors know what they are doing instead of trying to "fix" even
the last warning by whatever inappropriate means.
Regards,
Stefan
P.S.: Of course, I realize it's a problem if you have lots of bogus
warnings and can't even find the real problematic ones in
between them, but there must be a reasonable compromise
somewhere between "a lot" and "zero".
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
