>> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment