pgsql: Don't try to compile SSL CRL support if local SSL installation

Log Message:
-----------
Don't try to compile SSL CRL support if local SSL installation hasn't
got it. Per buildfarm failure on 'canary'.

Modified Files:
--------------
pgsql/src/backend/libpq:
be-secure.c (r1.66 -> r1.67)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/libpq/be-secure.c.diff?r1=1.66&r2=1.67)

On Thu, 4 May 2006, Tom Lane wrote:

> Log Message:
> -----------
> Don't try to compile SSL CRL support if local SSL installation hasn't
> got it. Per buildfarm failure on 'canary'.
>

It seems a little bit dangerous to just not check the CRL without so much
as a warning message. CRL support came around in openssl 0.9.7 which was
quite some time ago. Last time we discussed[1] this it looked like the
0.9.6 branch was still being maintained, but it's been over two years
since the last 0.9.6 release[2]. I'd suggest de-supporting 0.9.6 or some
sort of log message if there is a CRL file that we're not going to check.

Kris Jurka

[1] http://archives.postgresql.org/pgsql-committers/2005-07/msg00194.php
[2] http://www.openssl.org/news/

Kris Jurka <books(at)ejurka(dot)com> writes:
> On Thu, 4 May 2006, Tom Lane wrote:
>> Don't try to compile SSL CRL support if local SSL installation hasn't
>> got it. Per buildfarm failure on 'canary'.

> It seems a little bit dangerous to just not check the CRL without so much
> as a warning message.

[ shrug... ] Anyone who's running openssl 0.9.6, or whatever that is on
canary, isn't expecting CRL support anyway. And all I did is restore
the behavior we've had for lo these past many years.

regards, tom lane

Tom Lane wrote:
> Kris Jurka <books(at)ejurka(dot)com> writes:
> > On Thu, 4 May 2006, Tom Lane wrote:
> >> Don't try to compile SSL CRL support if local SSL installation hasn't
> >> got it. Per buildfarm failure on 'canary'.
>
> > It seems a little bit dangerous to just not check the CRL without so much
> > as a warning message.
>
> [ shrug... ] Anyone who's running openssl 0.9.6, or whatever that is on
> canary, isn't expecting CRL support anyway. And all I did is restore
> the behavior we've had for lo these past many years.

The problem is that we now document that we support CRL, so either we
log if we skip it, or we have to document which versions of OpenSSL do
not support CRL (yuck).

The attached patch checks for the file, and either user it or generates
a log message that it was skipped.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> The attached patch checks for the file, and either user it or generates
> a log message that it was skipped.

I still can't get excited about this. Who will it help? The DBA who is
silly enough to think his ancient SSL library supports CRL is probably
also silly enough not to read the postmaster log carefully. It would
make a whole lot more sense just to document that OpenSSL < whatever
doesn't support CRL.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > The attached patch checks for the file, and either user it or generates
> > a log message that it was skipped.
>
> I still can't get excited about this. Who will it help? The DBA who is
> silly enough to think his ancient SSL library supports CRL is probably
> also silly enough not to read the postmaster log carefully. It would
> make a whole lot more sense just to document that OpenSSL < whatever
> doesn't support CRL.

Why hard-code something if we can dynamically report it, and NetBSD 2.0
isn't that old.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +