* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > What bothers me about this is that it punts SSL work to the application
> > and requires that they be coded to work with both OpenSSL and whatever
> > else we implement (eg: GnuTLS) to do anything but the most simple
> > checks. That's a problem because people are *not* going to want to
> > #include both OpenSSL and GnuTLS headers into their applications because
> > they don't know which PG will be compiled with.. Not to mention that
> > it'd be darn awkward to do so.
>
> The point of this is to provide an escape hatch for people who really
> want to do XYZ even though we provide no API for XYZ in libpq. Hopefully,
> those people will be few and far between, because anything that's a really
> common requirement should be catered for by libpq.
I understand that, but 4 variables is pretty darn far from what an
application developing for SSL is going to want. As I've mentioned
before when this has been brought up, I'm of the opinion that we should
be providing, from the start, the same set as Apache's SSL environment
variables:
The mod_ssl (OpenSSL-based) documentation:
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
For mod_gnutls, this is the list of SSL variables provided:
http://www.outoforder.cc/projects/apache/mod_gnutls/docs/#environment-variables
Note that they're pretty much the same set, so providing them for
OpenSSL isn't closing off the ability to provide GnuTLS in the future.
To be clear, I'm not asking for all of this to happen in the first
patch, but I'd like whomever is going forward with this to at least
agree that they're going to try and cover the Apache set for whatever
libraries are supported in the first major release we put out with this.
Considering the example is already there, I'm really hopeful that isn't
too difficult to do..
Thanks,
Stephen
