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
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 |