From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Practical impediment to supporting multiple SSL libraries |
Date: | 2006-04-12 17:15:03 |
Message-ID: | 443D3597.1090402@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Lauzon | 2006-04-12 17:16:24 | Re: plpgsql by default |
Previous Message | Mischa Sandberg | 2006-04-12 17:07:33 | Re: Get explain output of postgresql in Tables |