On Monday 19 May 2008 15:27:24 dean gaudet wrote: > > 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?
Whoa, you're getting a tad trigger happy there. I'm not suggesting that testing the no-asm code is a valid way of testing the assembly code, you're putting words in my mouth. I think my last sentence is pretty clear. Debugging and optimising the assembly code is a different ball-game than identifying C-level leaks or other bugs in openssl. That's why I suggested comparing with a no-asm build. If valgrind sees equivalent problems in both, fine. If it sees it only with the assembly optimisations, that's useful information too, right? > additionally the suggestion of -DPURIFY as a way of testing the code is > also completely broken software engineering practice. No, it's not. This is a PRNG, not a menu widget. You might also want to test with support for symbols and core-dumps, but run without either in production. Heisenburgs can also up when running in a debugger vs not running a debugger, using optimisation flags selectively, [...]. We have a PRNG, the accent is on the "R", not the "P". This is not valgrind's fault, just a one-off incompatibility with the notion that "uninitialised"=="catastrophe". > any special case changes for testing means you're not testing the REAL > CODE. With respect, please check the "though shalts" at the door, thanks. > 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. This is not true. -DPURIFY does *NOT* compile out the use of *initialised* data - that is the whole point. It compiles out any use of *uninitialized* data. (Or at least it's supposed to, Bodo thinks there's another case where an #ifdef would be needed in the corner case where there's a short width parameter - that's beside the point.) > 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. Also not true. > 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. You haven't got your facts straight. In fact, I'm starting to suspect you've got them deliberately organised in a circle, for the sake of argument. Please make sure you're aware of *precisely* what's going on here, and *precisely* what -DPURIFY changes in openssl. Otherwise your second sentence is theologic, at best. > 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. More "thou shalts". As for your other mail; On Monday 19 May 2008 23:48:14 dean gaudet wrote: > On Thu, 15 May 2008, Bodo Moeller wrote: > > > The use of unititialized data in this case is stupid because the > > > entropy of this random data is close to zero. > > > > It may be zero, but it may be more, depending on what happened earlier > > in the program if the same memory locations have been in use before. > > This may very well include data that would be unpredictable to > > adversaries -- i.e., entropy; that's the point here. > > on the other hand it may be a known plaintext attack. For that sentence to be other than BS, it is a minimum requirement that the PRNG be fundamentally broken algorithmically. Please publish, or refrain from muddling the issue. > what are you guys smoking? The charred remains of a debian package, it's very noxious. Cheers, Geoff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
