Re: [PATCH] Automatic client certificate selection support for libpq v1

From: Seth Robertson <in-pgsql-hackers(at)baka(dot)org>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [PATCH] Automatic client certificate selection support for libpq v1
Date: 2009-05-11 16:44:00
Message-ID: 200905111644.n4BGi0Px003031@no.baka.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


In message <20090511144317(dot)GC8689(at)alvh(dot)no-ip(dot)org>, Alvaro Herrera writes:

Magnus Hagander wrote:

> Another thought: if we were to make ourselves support multiple SSL
> libraries (that has been suggested before - at that point, people wanted
> GnuTLS), we could also add support for Windows SChannel, which I'm sure
> some win32 people would certainly prefer - much easier to do SSL
> deployments within an existing MS infrastructure...

If we were to support multiple libraries, would they be selected at run
time or compile time? If only compile time, how would it work for the
Windows installer with the SChannel thingy --- would they have to
distribute two separate packages, for OpenSSL and SChannel?

While I have successfully performed runtime conditional dynamic
loading inside programs (each shared library with its own list of
dependent libraries) on one platform with one selected dynamic loading
API, I cannot say I recommend it. This would aid neither portability,
debug-ability, or performance (though compared to the overhead of SSL,
the jump table is kinda irrelevant).

-Seth Robertson
in-pgsql-hackers(at)baka(dot)org

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-11 16:48:31 DROP TABLE vs inheritance
Previous Message Seth Robertson 2009-05-11 16:36:44 Re: [PATCH] Automatic client certificate selection support for libpq v1