Re: Practical impediment to supporting multiple SSL libraries

On Wed, Apr 12, 2006 at 12:32:01PM -0400, Tom Lane wrote:
> 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.

The only real way to a solution is to work out why people want the
pointer. So far I've found two reasons:

- People want to hijack the connection after libpq has set it up to do
their own processing.

- People want to examine the certificates more closely.

The first would be easily handled by providing a formal interface for
libpq to hijack the connection with, providing read/write and maybe a
few others. The latter is tricker. You're invariably going to run into
the problem where the app uses one lib and libpq the other.

Other than DN and CN, what else would people want?
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.