In message <12314.1241809...@sss.pgh.pa.us>, Tom Lane writes:
Seth Robertson <in-pgsql-hack...@baka.org> writes:
> In message <8766.1241799...@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 become a project instead of a 5
> minute hack to support 80% of the functionality. I understand the
> desire to limit the number of hacks in the source code, though.
It's certainly possible that what you have done represents the best
available engineering tradeoff. But at this point it's too late for 8.4
and so we have quite a bit of time to think about it. I'd like to at
least consider alternative solutions before we choose this one.
BTW, I was reminded today that Fedora/Red Hat are hoping to standardize
all crypto-related functionality in their entire distro on the NSS
libraries:
I'm not sure that there would be benefits to us within the context
of Postgres alone. Is anyone sufficiently up on the 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-hack...@baka.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
