Re: new libpq SSL connection option

Alex Hunsaker wrote:
> On Fri, Dec 5, 2008 at 14:22, Andrew Chernow <ac(at)esilo(dot)com> wrote:
>> Alex Hunsaker wrote:
>>> On Fri, Dec 5, 2008 at 13:58, Andrew Chernow <ac(at)esilo(dot)com> wrote:
>>>> Who anyone be opposed to "ssldir = path" as a connection option?
>>>> Currently,
>>>> there is no way to change the homedir method ~/.postgresql ... or am I
>>>> missing something? I am willing to supply a patch.
>>> You mean something like the
>>>
>>> http://archives.postgresql.org/message-id/34d269d40811202107q489e2be0h771762398dd9fcdb@mail.gmail.com.
>>>
>>> ?
>>>
>> yes, excately like that; apparently missed it. What is the status of that
>> patch? I see it was left in pending review .. is the fest is over?
>
> I think all that is left is changing PGROOTCERT to PGSSLROOTCERT,
> agreeing to IFDEF the params out or not oh
> and this little bit:
>
>> Magnus Hagander escribió:
>>> On Fri, Aug 1, 2008 at 13:31, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
>>>> Something that's bothering me is that PGSSLKEY is inconsistent with the
>>>> sslkey conninfo parameter. PGSSLKEY specifies an engine (basically a
>>>> driver for specialized hardware AFAICT) from which the key is to be
>>>> loaded, but sslkey is a simple filename. This means that there's no way
>>>> to load a key from hardware if you want to specify it per connection.
>>>> Not that I have any such hardware, but it looks bogus.
>
>> I think the above consideration needs some discussion too. Committing
>> it as-is doesn't seem OK because you can't change it later -- it's
>> user-visible.

Here's a suggested update, which does *not* yet have documentation
updates. Changes from previous patch:

* Made all parameters available always and ignored for non-SSL connections
* Renamed PGROOTCERT to PGSSLROOTCERT
* Changes the way PGSSLKEY/sslkey is handled to this: When the string
does not contain a colon, it's treated as a filename. If it does contain
a colon (and on windows, if this colon is not in the second position
indicating a drive letter), it's treated as engine:key as before.

This should keep backwards compatibility.

I would also like to look this over completely - we only support loading
the KEY from the smartcard, but you still have to manually copy the
certificate to your machine. I don't know exactly how you're supposed to
do this in OpenSSL - some googling shows almost nobody else uses the
functions quite the way we do. So I'd like to look over if we need to do
more around this later, but this patch should make it possible to use
keys from different files without breaking backwards compatibility with
what we had before. So I'm considering that a separate step, that may
not be done in time for 8.4.

So. Comments?

//Magnus