Re: [HACKERS] SSL and USER_CERT_FILE

>
> On May 15, 2008, at 6:31 AM, pgsql@mohawksoft.com wrote:
>
>>> Mark Woodward wrote:
>>>> I am using PostgreSQL's SSL support and the conventions for the
>>>> key and
>>>> certifications don't make sense from the client perspective.
>>>> Especially
>>>> under Windows.
>>>>
>>>> I am proposing a few simple changes:
>>>>
>>>> Adding two API
>>>> void PQsetSSLUserCertFileName(char *filename)
>>>> {
>>>> user_crt_filename = strdup(filename);
>>>> }
>>>> PQsetSSLUserKeyFileName(char *filename)
>>>> {
>>>> user_key_filename = strdup(filename);
>>>> }
>>>>
>>>>
>>>>
>>> [snip]
>>>> Any comments?
>>>>
>>>>
>>>
>>>
>>> I think it would probably be much better to allow for some
>>> environment
>>> variables to specify the locations of the client certificate and key
>>> (and the CA cert and CRL) - c.f. PGPASSFILE.
>>>
>>> That way not only could these be set by C programs but by any libpq
>>> user
>>> (I'm sure driver writers who use libpq don't want to have to bother
>>> with
>>> this stuff.) And we wouldn't need to change the API at all.
>>>
>>
>> The problem I have with environment variables is that they tend not
>> to be
>> application specific and almost always lead to configuration issues.
>> As a
>> methodology for default configuration, it adds flexibility. Also, the
>> current configuration does not easily take in to consideration the
>> idea
>> that different databases with different keys can be used from the same
>> system the same user.
>
> Environment variables don't have to be set in your shell.
>
> This would seem to give the same functionality you suggest above,
> given support for environment variables:
>
> void PQsetSSLUserCertFileName(char * filename)
> {
> setenv("PGCERTFILE", filename);
> }
>
> void PQsetSSLUserKeyFileName(char *filename)
> {
> setenv("PGKEYFILE", filename);
> }
>
> Or, in perl, $ENV{PGKEYFILE} = $file and so on. It seems
> less intrusive than adding new API calls.
>
> Cheers,
> Steve

Doesn't it make sense that the connection be configured in one place? I
agree with Tom, if it should be done, it should be done in PQconnectdb.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers