Bruce Momjian wrote:
> Andrew Chernow wrote:
>> I am using a library that links with and initializes libcrypto (ie.
>> CRYPTO_set_locking_callback) but not SSL. This causes problems even
>> when using PQinitSSL(FALSE) because things like SSL_library_init(); are
>> not called (unless I manually call them, copy and paste code from
>> fe-secure.c which may change). If libpq does init ssl, it overwrites
>> (and breaks) the other library's crypto.
>>
>> Shouldn't crypto and ssl init be treated as two different things? If
>> not, how does one determine a version portable way of initializing SSL
>> in a manner required by libpq? Lots of apps using encryption but don't
>> necessarily use ssl, so they need to know how to init ssl for libpq.
>
> I didn't realize they were could be initialized separately, so we really
> don't have an answer for you. This is the first time I have heard of
> this requirement.
>
Just bringing it to everyones attention. I have no idea how common this
use case is or if it deserves a patch. From your comments, it sounds
uncommon.
How we came across this:
We have an internal library that links with libcrypto.so but not
libssl.so. The library uses digests and ciphers from libcrypto. It
initializes libcrypto for thread safety and seeds the PRNG. So, one of
our applications is linking with both libpq and this library; which
caused the conflict.
How we worked around it:
We solved it by copying the SSL init sequence from fe-secure.c. Doesn't
seem like something that would change very often. So we
init_our_library(), PQinitSSL(0) and then do a few lines of SSL init stuff.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
