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