Re: PQinitSSL broken in some use casesf - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: PQinitSSL broken in some use casesf
Date
Msg-id 200903290403.n2T43jG23323@momjian.us
Whole thread Raw
In response to Re: PQinitSSL broken in some use casesf  (Andrew Chernow <ac@esilo.com>)
Responses Re: PQinitSSL broken in some use casesf  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andrew Chernow wrote:
> Robert Haas wrote:
> > 
> > Is there more substance here than meets the eye?
> > 
> 
> No, you about summed it up.  We need a way to init libssl and libcrypto 
> in any combo.  Along the way, PQinit() was discussed which may have 
> muddied the waters.
> 
> I prefer leaving the PQinitSSL function alone, thus my patch that 
> implements PQinitSecure(flags).
> 
> Adding PQinitSSL(new_value) seem reasonable to me.  My only complaint 
> has been that the API user has no way of knowing if the function 
> understood their request.  An older libpq would treat any non-zero 
> argument as one, which would silently fail/mis-behave from a new apps 
> perspective.  Not sure this can be solved.
> 
> In the end, anyway you do it will have an issue or two.  I agree that it 
> really doesn't matter, all methods would probably do the trick.

I think doing PQinitSSL(new_value) is probably the least invasive change
to solve this, which is why I suggested it.  It does have a compile-time
check by referencing the #define.

We never documented the valid values to PQinitSSL(), and no one ever
reported this as a bug, so the existing use of PQinitSSL() is probably
very small.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Andrew Chernow
Date:
Subject: Re: PQinitSSL broken in some use casesf
Next
From: Guillaume Smet
Date:
Subject: Re: 8.4 release notes proof reading 1/2