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