Re: Question regarding OpenSSL Security Advisory

2010-11-17 Thread David Schwartz

On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote:


Hi,
I had some questions about the latest security advisory. I understand
that this applies to multi-threaded application while using ssl sessions.


Correct.


If the application is written thread safe using
CRYPTO_set_locking_callback functions will the vulnerability still apply ?


If it didn't, it wouldn't be a vulnerability at all.


If the ssl code calls the locking callback function before accessing the
internal session cache then the vulnerability should not
apply to above mentioned applications.


Right, it shouldn't, but it does. That's what makes it a vulnerability. 
Code not working under conditions where it cannot be expected to work is 
not a vulnerability, it's simply misuse. This is a vulnerability because 
it affects applications that use the code correctly.


DS

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Overridden custom rpath

2010-11-17 Thread Philippe A.
Hello,

I am having difficulty compiling openssl 1.0.0a with a custom rpath RHEL
5.5. My objective is to compile with the relative rpath ../lib64.

./config  -Wl,-rpath,../lib64 --prefix=/usr/local/app/openssl
--install_prefix=~/tmp/openssl-install shared

After compilation, I check what library is used by openssl with ldd. I see
it point to a previous installation in /usr/local/app/openssl. With strings,
I see a path in front of mine:

/usr/local/app/openssl/lib64:../lib64

To get rid of the undesired rpath, I need to remove the following from
Makefile:

LIBRPATH='$(INSTALLTOP)/$(LIBDIR)'

Is there a way to control LIBRPATH without editing Makefile? Why does
another rpath get added in front of mine anyway?

Thank you!