dean gaudet wrote:
On Thu, 15 May 2008, Geoff Thorpe wrote:
I forgot to mention something;
If you're using an up-to-date version of openssl when you see this (ie. a
recent CVS snapshot from our website, even if it's from a stable branch for
compatibility reasons), then please post details. -DPURIFY exists to
facilitate debuggers that don't like reading uninitialised data, so if
that's not the case then please provide details. Note however that there
are a variety of gotchas that allow you to create little leaks if you're
not careful, and valgrind could well be complaining about those instead.
Note that you should always build with "no-asm" if you're doing this kind of
debug analysis. The assembly optimisations are likely to operate at
granularities and in ways that valgrind could easily complain about. I don't
know that this is the case, but it would certainly make sense to compare
before posting a bug report.
you know, this is sheer stupidity.
you're suggesting that testing the no-asm code is a valid way of testing
the assembly code?
additionally the suggestion of -DPURIFY as a way of testing the code is
also completely broken software engineering practice.
any special case changes for testing means you're not testing the REAL
CODE.
Where is the problem with it? When you add debugging print statements
for finding an error, you are also not testing the "real code", but when
you have found the error, you can remove the print statements and are
back to the "real code". With -DPURIFY you can do the same.
for example if you build -DPURIFY then you also won't get notified of
problems with other PRNG seeds which are supposed to be providing random
*initialized* data. not to mention that a system compiled that way is
insecure -- so you either have to link your binaries static (to avoid the
danger of an insecure shared lib), or set up a chroot for testing.
Why is a system built with -DPURIFY insecure? I presume you don't
understand what -DPURIFY does.
in any event YOU'RE NOT TESTING THE REAL CODE. which is to say you're
wasting your time if you test under any of these conditions.
openssl should not be relying on uninitialized data for anything. even if
OpenSSL doesn't rely on uninitialized data!
it doesn't matter from the point of view of the PRNG, it should be pretty
damn clear it's horrible software engineering practice.
It's not at all clear that putting uninitialized data into a PRNG is bad
software engineering practice, there may be circumstances where it is
the last resort (imagine e.g. that the debian developer would have
killed /dev/random instead).
Ciao,
Richard
--
Dr. Richard W. Könning
Fujitsu Siemens Computers GmbH
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
