Subject: Re: Improve errors when setting incorrect bounds for SSL protocols
To: Michael Paquier <michael@paquier.xyz>, Daniel Gustafsson <daniel@yesql.se>
References: <20200114035420.GE1515@paquier.xyz>
 <E51AB0A2-2282-446E-B88B-055900259BFE@yesql.se>
 <20200115022805.GB2243@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <5342043b-c85f-2fb9-7934-45cf6a64b200@2ndquadrant.com>
Date: Mon, 20 Jan 2020 09:11:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20200115022805.GB2243@paquier.xyz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2020-01-15 03:28, Michael Paquier wrote:
> Good points.  And the get routines are not that portable in OpenSSL
> either even if HEAD supports 1.0.1 and newer versions...  Attached is
> an updated patch which uses a GUC check for both parameters, and
> provides a hint on top of the original error message.  The SSL context
> does not get reloaded if there is an error, so the errors from OpenSSL
> cannot be triggered as far as I checked (after mixing a couple of
> corrent and incorrect combinations manually).

The reason this wasn't done originally is that it is not correct to have 
GUC check hooks that refer to other GUC variables, because otherwise you 
get inconsistent behavior depending on the order of processing of the 
assignments.  In this case, I think it would work because you have 
symmetric checks for both variables, but in general it is a problematic 
strategy.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services