Skip site navigation (1) Skip section navigation (2)

Re: PQinitSSL broken in some use casesf

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andrew Chernow <ac(at)esilo(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PQinitSSL broken in some use casesf
Date: 2009-03-29 04:03:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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(at)momjian(dot)us>

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

In response to


pgsql-hackers by date

Next:From: Guillaume SmetDate: 2009-03-29 09:52:01
Subject: Re: 8.4 release notes proof reading 1/2
Previous:From: Andrew ChernowDate: 2009-03-29 03:24:56
Subject: Re: PQinitSSL broken in some use casesf

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group