On May 15, 2008, at 6:31 AM, [EMAIL PROTECTED] 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
