On Thu, 15 May 2008, Geoff Thorpe wrote:

> I forgot to mention something;
> 
> > On Thursday 15 May 2008 12:38:24 John Parker wrote:
> > > >> > It is already possible to use openssl and valgrind - just build
> > > >> > OpenSSL with -DPURIFY, and it is quite clean.
> > >
> > > Actually on my system, just -DPURIFY doesn't satisfy valgrind.  What
> > > I'm asking for is something that both satisfies valgrind and doesn't
> > > reduce the keyspace.
> >
> > 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.

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.

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 
it doesn't matter from the point of view of the PRNG, it should be pretty 
damn clear it's horrible software engineering practice.

-dean
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to