Re: Practical impediment to supporting multiple SSL libraries

> > 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?

Issuer (name and certificate), validity dates, basic constraints, key
usage, posslby fingerprint.

//Magnus