> Agreed, though where possible it's preferable for PURIFY-handling > to simply > not use the uninitialised data at all, rather than initialising it before > use. (NB, I know this yields the same quality result, but > appearances in the > code are often as important as the outcome of the executable - > particularly > where package maintainers are concerned...) IIRC, it's > complicated to remove > the (uninitialised) loads here without also removing the desired > stores, in > which case I totally agree that memset(,0,) is a more obvious > PURIFY(/valgrind) workaround. But where it's possible to trim our > use of an > input buffer so that we don't take some uninitialised > "trimmings", then the > intent of the code would be much clearer. Moreover, it's more > likely valgrind > would then find bugs in the PRNG code (if ever we accidently debianise it > ourselves) - whereas wholesale memset()s kind of limit the > effectiveness of > such debugging tools.
FWIW, I don't agree. Defining PURIFY should not make algorithmic changes. How much data a call passes to the PRNG is an algorithmic change. Initializing data to zeroes that would otherwise be uninitialized (and could be zeroes anyway for all we know) is much more palatable than passing a different length down a call chain. > Or put another way, -1 to the suggested patch. Also, -1 to the general > statement that "PURIFY is *not* for production system". That is > not our call > to make! If the production system is experiencing problems and is being > diagnosed - it may very well make sense to run it under > PURIFY/valgrind to > help track down problems that have only been observed in > production. (Anyone > who has ever tried to gaze into a crystal ball and invent a test-case to > reproduce sporadic problems from a production system will know what I'm > talking about). I agree. PURIFY should not make any algorithmic changes, unless they are absolutely necessary. Ideally, IMO, defining PURIFY should cause all, and only, uninitialized data to be zeroed. That way, if we don't initialize something we meant to, it will still be caught. Just zeroing things we plan to set to other values later is an inferior solution. But changing the amount of data we pass to the PRNG is an inferior solution too. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
