Re: Practical impediment to supporting multiple SSL libraries

Tom Lane 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.
> 
> 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 wonder if there are apps that actually use the ssl pointer, beyond 
detection of encrypted connections. So interpreting the result as bool 
would be sufficient.

Regards,
Andreas