Re: A successor for PQgetssl

* Martijn van Oosterhout (kleptog@svana.org) wrote:
> The intention is not to provide access to everything. If people want to
> know more about the certificate, we simply export the certificate to
> them and they can do with it what they like, including sending it to
> another program. I wasn't expecting that list to grow much because
> there's not much to export.
>
> Besides, what's wrong with read-only access? What parameters were you
> expecting them to want to change? After a session is setup there are no
> parameters to change anymore. All you need is read and write.

I have to agree with this...  Certificate handling isn't growing new
things in leaps and bounds these days and as long as the certificates
are available to the user then the other things are really just
nicities for people who don't want to decode the certs themselves.

> > a lot of time on our part that could be better spent elsewhere, plus a
> > lot of time on the part of app programmers rewriting existing
> > OpenSSL-aware or GnuTLS-aware code to instead use whatever random API we
> > tell them they ought to use.  They have better things to do with their
> > time, too.
>
> The whole point is that app writers should not be aware at all which
> library we're using. At the moment psqlODBC requires openssl because we
> force them to. They only use three OpenSSL functions, SSL_read,
> SSL_write, and SSL_get_error.
>
> If we provided a hook to allow people read/write directly, they
> wouldn't need to know about the SSL connection at all. I think that's a
> much better way to go than adding a new library specific function for
> every little feature we add.

I have to agree with Martijn here too.  It's not all that expensive to
provide read/write calls to abstract away the specific library being
used (since psqlODBC, at least, couldn't care less which library is
being used, really) rather than ask for application developers to write
their apps to support multiple SSL libraries to handle the case where
libpq is compiled with one library vs. compiled with another...

> > > - This breaks psqlODBC when it uses libpq because it wants to use OpenSSL
> > > and when libpq is compiled with GnuTLS that obviously won't work.
> >
> > That alone is sufficient reason why we're not going down that path.
> > If we expose a GnuTLS-handle-fetching API then it's up to the ODBC
> > guys to extend their code to handle that SSL library when they feel
> > like it.  But telling them that we're simply going to break their
> > code and not provide them a path to fix it is not happening.
>
> By going down this path you're saying that psql will never be able
> display the cipher of an SSL connection if the libpq was compiled with
> a different library. If we provide a read/write than psqlODBC can
> remove code and it will work with GnuTLS. Isn't that much better?

I didn't really understand Tom's point here either...  In order to not
break psqlODBC when libpq is compiled with GnuTLS we'd have to code up
support for returning an SSL* from the GnuTLS library that would work
for all the OpenSSL functions which just isn't going to happen...  I
agree that we probably shouldn't go out of our way to break psqlODBC
when libpq is compiled with OpenSSL (and so we shouldn't really change
PQgetssl but mark it obsolete and ask that people don't use it and
provide some other way for psqlODBC to do what it wants, or not, perhaps
return NULL when using GnuTLS or '0x1', or not define it when libpq is
compiled with GnuTLS...).
Thanks,
    Stephen