I have submitted a patch that does two things: (1) fixes a bug in the
client SSL code that never appended the home directory to the root
revocation list. and (2) adds 4 new fields to the connect string:
sslkey=fullepath_to_file
sslcert=fullpath_to_cert
ssltrustcrt=fullpath_to_trusted_cert_file
ssl
> [EMAIL PROTECTED] wrote:
>> > [EMAIL PROTECTED] 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 ot
[EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] 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 libp
[EMAIL PROTECTED] wrote:
I think if you're going to provide for these then you should also
provide for the CA cert and CRL.
Otherwise, it seems sensible.
I thought about that, but the root and crl are for the server, and that
makes sense that the keys would be in the server directo
>
>
> [EMAIL PROTECTED] wrote:
>> Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
>>
>> After some discussion, I think it is more appropriate to add the
>> key/cert
>> file for SSL into the connect string. For example:
>>
>> PQconnectdb("host=foo dbname=bar sslmode=require
>> ss
[EMAIL PROTECTED] wrote:
Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
After some discussion, I think it is more appropriate to add the key/cert
file for SSL into the connect string. For example:
PQconnectdb("host=foo dbname=bar sslmode=require
sslkey=/opt/myapp/share/ke
Adding "sslkey" and "sslcert" to the PQconnectdb connection string.
After some discussion, I think it is more appropriate to add the key/cert
file for SSL into the connect string. For example:
PQconnectdb("host=foo dbname=bar sslmode=require
sslkey=/opt/myapp/share/keys/client.key
sslcert=/opt/my
>
> 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
> [EMAIL PROTECTED] 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.
>
>
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
vo
[EMAIL PROTECTED] 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.
> 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 *filen
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_
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(filenam
14 matches
Mail list logo