Re: libpq should not be using SSL_CTX_set_client_cert_cb

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Garick Hamlin <ghamlin(at)isc(dot)upenn(dot)edu>
Cc: "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: libpq should not be using SSL_CTX_set_client_cert_cb
Date: 2010-05-26 16:21:53
Message-ID: 13714.1274890913@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Garick Hamlin <ghamlin(at)isc(dot)upenn(dot)edu> writes:
> One could make it work with multiple TAs in a similar fashion if it also
> checked for the existence of a directory (like: ~/.postgresql/client_ta ) to
> store chains to each supported TA by fingerprint.

> That might not be worth the effort at this point...

I'm inclined to think not. You can instruct libpq to send a non-default
certificate file by setting its sslcert/sslkey parameters, and I think
what people would typically do is just treat those as known properties
of each server connection they have to deal with. Implementing cert
selection logic inside libpq would simplify such cases, but I can't see
that anybody is likely to get around to that anytime soon.

Chained certs, on the other hand, definitely are in use in the real
world, so we'd better fix libpq to handle that case.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-05-26 16:38:51 Re: Exposing the Xact commit order to the user
Previous Message Jan Wieck 2010-05-26 16:10:18 Re: Exposing the Xact commit order to the user