On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Aug 18, 2014 at 7:54 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> In order to support alternatives to OpenSSL, we need to wean off
>> applications from using PQgetssl(). To do that, we have to provide an
>> alternative API to get the same information. PQgetSSL() returns a pointer
>> directly to the OpenSSL private struct, and you can do anything with that.
>> We cannot have a generic interface that exposes everything, so we need to
>> identify the information that people actually want, and expose that.
>
> I have a hard time believing that something like this will really
> satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and
> call it good? We can try to be incredibly thorough in exposing the
> information people want and we will still inevitably miss something
> that someone cares about; worse, we'll spend an awful lot of time and
> energy along the way.
Well, for one you push the full burden onto the application. Then
every application has to support every SSL library we do, even for the
simplest check. And it has to be built against the same one. (So for
example if someone wants to use openssl on windows - yes there might
still be reasons for that even if we support schannel - they have to
rebuild every one of their applications. And every one of their higher
level language drivers sitting on top of openssl).
The same problem of course appears on say Linux, if you end up using a
mix of openssl and gnutls or a mix of nss and openssl for example.
It's not likely to happen as long as you only use the officially built
packages, but you're likely in for quite a bit of pain if you are
using any non-standard packaging like the oneclick installers etc.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
