Re: SSL and USER_CERT_FILE

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: pgsql(at)mohawksoft(dot)com
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql(at)mohawksoft(dot)com, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSL and USER_CERT_FILE
Date: 2008-05-15 18:10:33
Message-ID: 20080515201033.20a83789@mha-laptop.hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

pgsql(at)mohawksoft(dot)com wrote:
> > pgsql(at)mohawksoft(dot)com writes:
> >> Maybe we need to go even further and add it to the PQconnect API
> >> sslkey=filename and sslcrt=filename in addition to sslmode?
> >
> > If there's a case to be made for this at all, it should be handled
> > the same way as all other libpq connection parameters.
> >
> > regards, tom lane
> >
>
> Here's the use case:
>
> I have an application that must connect to multiple PostgreSQL
> databases and must use secure communications and the SSL keys are
> under the control of the business units the administer the databases,
> not me. In addition my application also communicates with other SSL
> enabled versions of itself.
>
> I think you would agree that a hard coded immutable location for
> "client" interface is problematic.

I agree fully with the use-case. Most of the other things we allow both
as connection parameters and as environment variables, so we should do
that IMHO. What could be debated is if we should also somehow allow it
to be specified in .pgpass for example?

//Magnus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-05-15 18:19:16 Re: libpq object hooks
Previous Message Tom Lane 2008-05-15 18:08:03 Re: libpq object hooks