Re: OpenSSL 3.0.0 compatibility - Mailing list pgsql-hackers

> On 30 May 2020, at 11:29, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2020-05-29 14:45, Daniel Gustafsson wrote:
>>> I think we should set OPENSSL_API_COMPAT=10001, and move that along with whatever our oldest supported release is
goingforward.  That declares our intention, it will silence the deprecation warnings, and IIUC, if the deprecated stuff
actuallygets removed, you get a clean compiler error that your API level is too low. 
>> I think I know what you mean but just to clarify: I master, back-branches or
>> all of the above?
>
> I'm not sure.  I don't have a good sense of what OpenSSL versions we claim to support in branches older than PG13.
Wemade a conscious decision for 1.0.1 in PG13, but I seem to recall that that discussion also revealed that the version
assumptionsbefore that were quite inconsistent.  Code in PG12 and before makes references to OpenSSL as old as 0.9.6.
ButOpenSSL 3.0.0 will reject a compat level older than 0.9.8. 
>
> My proposal would be to introduce OPENSSL_API_COMPAT=10001 into master after the 13/14 branching, along with any
otherchanges to make it compile cleanly against OpenSSL 3.0.0.  Once that has survived some scrutiny from the buildfarm
andalso from folks building against LibreSSL etc., it should probably be backpatched into PG13.  In the immediate
future,I wouldn't bother about the older branches (<=PG12) at all.  As long as they still compile, users can just
disabledeprecation warnings, and we may add some patches to that effect at some point, but it's not like OpenSSL 3.0.0
willbe adopted into production builds any time soon. 
>
>> Considering how little effort it is to not use the deprecated API's I'm not
>> entirely convinced, but I don't have too strong opinions there.
>
> Well, in the case like X509_STORE_load_locations(), the solution is in either case to write a wrapper.  It doesn't
matterif we write the wrapper or OpenSSL writes the wrapper.  Only OpenSSL has already written the wrapper and has
createda well-defined way to declare that you want to use the wrapper, so I'd just take that. 

I'll buy that argument.

> In any case, using OPENSSL_API_COMPAT is also good just for our own documentation, so we can keep track of what
versionwe claim to support in different branches. 

Good point.

>>> There is also the question of what to do with the test suites in the back branches.
>> If we don't want to change the testdata in the backbranches, we could add a
>> SKIP section for the password key tests iff OpenSSL is 3.0.0+?
>
> I suggest to update the test data in PG13+, since we require OpenSSL 1.0.1 there.  For the older branches, I would
lookinto changing the test driver setup so that it loads a custom openssl.cnf that loads the legacy providers. 

Ok, I'll roll a patch along these lines for master for ~ the 13/14 branch time
and then we'll see how we deal with PG13 once the dust has settled not only on
our side but for OpenSSL.

cheers ./daniel