>If you want to debug with OpenSSL you must compile a debugging version,
>if you want to profile with OpenSSL you must compile a profiling
>version, if you want to use valgrind with OpenSSL you must compile a
>valgrind version, yadda, yadda.
Which is fine - IF you have access to the sources of the code that uses
OpenSSL. Im my case we supply libraries that customers integrate with other
code - often other 3rd party code.
If this decreased security, or had any real performance impact, I'd
understand the objections - but that doesn't appear to be the case.
>Would I be correct in saying that OpenSSL uses the implied randomness of
>the data on the stack to add randomness to the result. By virute of
>using uninitialized data as a source of randomness it is this that is
>causing the problem (then it gets used by the app and one or more bytes
>find their way into what valgrind believes is dangerous usage and
>therefore a warning gets emitted) ?
Yes, but it isn't very random anyway. Just uninitialized. i.e. it may have
the same value every time the program starts.
In reality it isn't a major problem for me, since I solved this years ago,
but I can still remember how annoying it was at the time. And since IBM
isn't the only comemercial user of OpenSSL you may want to consider not
drowning one of the better debug tools available in spam every time OpenSSL
is in the process.
Peter
Darryl Miles
<darryl-mailingli
[EMAIL PROTECTED]> To
Sent by: openssl-dev@openssl.org
owner-openssl-dev cc
@openssl.org
Subject
Re: [patch] Valgrind complaining
05/03/07 03:51 PM about unitialized data
Please respond to
openssl-dev
Peter Waltenberg wrote:
> Valgrind runs on unmodified binaries - and it's not always possible to
> get someone else to recompile their code so that you can find problems.
> OpenSSL is used in commercial products where source isn't always
> available.
This does not mean the valgrind ready version of a library is the same
version as a general purpose optimized that you might use in a
production environment.
If you need to use valgrind then you must accept that you need to be in
the position to audit ALL of the code that makes up your application to
play nice with valgrind.
It is not the OpenSSL project's place to make your commercial product
development work best for you in your environment.
If you want to debug with OpenSSL you must compile a debugging version,
if you want to profile with OpenSSL you must compile a profiling
version, if you want to use valgrind with OpenSSL you must compile a
valgrind version, yadda, yadda.
I think you take the valgrind marketing feature "Valgrind runs on
unmodified binaries" far too literally. You have to also account for
the flaws in how valgrind is implemented, some people could argue that
valgrind should have a rule to cater for this exact problem just like it
already does for many quirks of popular libc implemtations and system
calls. But it doesn't at this time and I accept that and I accept that
-DPURFY is fine for me.
I would not be against any fix which has no performance impact and given
its this one little line I'd also like to hear the case for why things
should be left as they are.
Would I be correct in saying that OpenSSL uses the implied randomness of
the data on the stack to add randomness to the result. By virute of
using uninitialized data as a source of randomness it is this that is
causing the problem (then it gets used by the app and one or more bytes
find their way into what valgrind believes is dangerous usage and
therefore a warning gets emitted) ?
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
