On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Merlin Moncure wrote:
>> > PQinitSSL(0) was specifically designed to allow applications to set up
>> > SSL on their own. How does this not work properly?
>>
>> this has nothing to do with who initializes ssl. this is all about
>> *crypto*. remember, crypto and ssl are two separate libraries. The
>> application or library in question may not even link with ssl or use
>> ssl headers.
>>
>> The problem is PQinitSSL (re-) initializes crypto without asking if that's ok.
>
> PQinitSSL(false) initializes crypto? Please point me to exact function
> calls that are the problem? Everything is very vague.
nooo, you are not listening :-)
PQinitSSL(0) initializes libpq for ssl but leaves crypto and ssl
initialization to the app
PQinitSSL(1) initializes libpq, crypto, and ssl libraries
Now, consider an app that uses libcrypto for its own requirements *but
not libssl*. It initializes libcrypto, passing its own lock vector,
etc. It cannot however initialize ssl because it does not link with
ssl, or include ssl headers. There are no ssl functions to call, and
it wouldn't make sense to expect the app to do this even if there
were.
Now, if this app also has libpq dependency, it needs a way to tell
libpq: 'i have already initialized the crypto library, but could you
please set up libssl'. otherwise you end up re-initializing libcrypto
with different lock vector which is very bad if there are any locks
already in use, which is quite likely.
There is no way to do that with libpq....so you see that no matter how
you call PQinitSSL, the application is broken in some way. Passing 0
breaks because ssl never ends up getting set up, and passing 1 breaks
because libcrypto's locks get messed up.
The main problem is that libpq PQinitSSL makes broad (and extremely
dangerous assumption) that it is the only one interested in libcrypto
lock vector. In short, it's broken.
merlin