On 02/17/2011 04:09 PM, Martijn van Oosterhout wrote:
> On Wed, Feb 16, 2011 at 04:33:19PM -0800, Joshua D. Drake wrote:
>> Maybe we really should consider moving to NSS insread?
>>
>> http://www.mozilla.org/projects/security/pki/nss/
>>
>> If it solves the license problem, it is well supported etc..
> For the record, which library you choose only matters for a fairly
> small (and easy) part of the patch. Changing libpq to be SSL library
> agnostic is more work.
>
> For the people who aren't following, the issue is there are libraries
> out there that use libpq to setup the connection to the postgres server
> (so handing all authentication, et al) and then stealing the FD and
> implementing the rest of the protocol themselves.
>
> This is supported. Where it goes wonky is that this also has to work
> when the connection is via SSL. So libpq provides a function to return
> (via a void*) a pointer to the OpenSSL structure so that can be used to
> communicate with the server.
Ugh. Maybe not the best design decision we've ever made.
> As you can imagine, unless the library you use is *binary* compatable
> with OpenSSL, you're kinda stuck. The idea I suggested way back was to
> introduce a passthrough mode which would hide all the connection
> details within libpq, simplifying the code on both sides. Then after a
> few releases you could remove the old code and change the SSL library
> at leasure.
>
> I guess the painless option however is no longer available.
>
Could we provide an abstraction layer over whatever SSL library is in
use with things like read/write/poll? Maybe that's what you had in mind
for the passthrough mode.
cheers
andrew