Re: libpq should not be using SSL_CTX_set_client_cert_cb

Craig Ringer <craig@postnewspapers.com.au> writes:
> On 27/05/10 10:21, Tom Lane wrote:
>> What will happen as things stand is that all the certs get loaded
>> into a common pool.  That's not too horrible as long as there are
>> not actual conflicts, but it could mean that for example some
>> connections trust CA certs that the app programmer expected to only
>> be trusted for other connections.  I did arrange (and test) that the
>> client cert and key are local to each connection, but leakage of
>> trusted root certs is a different story.

>> We could avoid this problem if we were willing to set up a separate
>> SSL_context for each connection, but I'm not sure if it's worth that.
>> The scenario where a single application process is managing multiple
>> distinct sets of trusted certs seems a bit far-fetched anyway.

> OpenSSL really doesn't seem to be designed for multiple truly 
> independent SSL contexts. The SSL context stuff has clearly been hacked 
> on after the fact to a library that started out having only one global 
> state, and it's pretty incomplete. I'm honestly not sure it's worth 
> trying to allow per-connection trust going, especially as (AFAIK) 
> there's no evidence that anybody _wants_ per-client-connection SSL trust 
> anyway.

Precisely.  I'm not excited about doing anything about this in the near
term, or even the not-so-near term.  I just wanted to get the
information into the PG archives in case it ever does become
significant.
        regards, tom lane