* Tom Lane ([EMAIL PROTECTED]) wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: > > 1. Changing it to always return (void*), irrespective of SSL > > ... > > Personally, I'm in favour of 1, because then we can get rid of the > > #include for openssl, so users don't have to have openssl headers > > installed to compile postgresql programs. > > I like that too. I've never been very happy about having libpq-fe.h > depending on USE_SSL.
I'm all in favor of dropping the dependency on OpenSSL headers from
libpq, just to throw my 2 cents in there.
> There is a more serious issue here though: if we allow more than one SSL
> library, what exactly can an application safely do with the returned
> pointer? It strikes me as very dangerous for the app to assume it knows
> which SSL library is underneath libpq. It's not at all hard to imagine
> an app getting an OpenSSL struct pointer and trying to pass it to GnuTLS
> or vice versa. To the extent that there are apps out there that depend
> on doing something with this function, I think that even contemplating
> supporting multiple SSL libraries is a threat.
I'm afraid the way to do this would probably be to have it return a
Postgres-defined structure (without depending on if it's compiled with
SSL or not) which then indicates if the connection is SSL-enabled or not
and then probably other 'common' information (remote DN, remote CA,
ASN.1 formatted certificate perhaps, etc...).
Thanks,
Stephen
signature.asc
Description: Digital signature
