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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
