Andrew Chernow wrote:
> 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.
Seems unusual, but certainly not "nearly impossible". But we're back to
the discussions around the WSA code - our API provides no really good
place to do this, so perhaps we should just clearly document how it's
done and how to work around it?
//Magnus