In message <12314.1241809436@sss.pgh.pa.us>, Tom Lane writes:
Seth Robertson <in-pgsql-hackers@baka.org> writes: > In message <8766.1241799013@sss.pgh.pa.us>, Tom Lane writes:
>> Hmm, shouldn't we fix *that* rather than inventing a hack like this? > Basically doing this would probably
becomea project instead of a 5 > minute hack to support 80% of the functionality. I understand the > desire to
limitthe number of hacks in the source code, though. It's certainly possible that what you have done represents
thebest available engineering tradeoff. But at this point it's too late for 8.4 and so we have quite a bit of time
tothink about it. I'd like to at least consider alternative solutions before we choose this one. BTW, I was
remindedtoday that Fedora/Red Hat are hoping to standardize all crypto-related functionality in their entire distro
onthe NSS libraries:
I'm not sure that there would be benefits to us within the context of Postgres alone. Is anyone sufficiently up
onthe different crypto libraries to comment on that?
I am not perfectly up to speed, but switching to NSS would solve this
(automatic client certificate selection) problem in the crypto
library, since NSS supports a client certificate database and
furthermore has a default callback function NSS_GetClientAuthData
which searches the certificate database for a suitable match. It also
supports OCSP (online certificate status protocol) which is an online
certificate revocation check (better than the current TODO item of
"Allow SSL CRL files to be re-read during configuration file reload,
rather than requiring a server restart").
Well, I guess that openssl supports OCSP as well, but the support does
not seem as complete (no AIA support--revocation URL embedded in the
certificate--that I can see).
It is of course possible to support both at the same time (at
compile-time, if nowhere else).
-Seth Robertson in-pgsql-hackers@baka.org
