Re: OpenSSL 3.0.0 compatibility

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.  We made a conscious 
decision for 1.0.1 in PG13, but I seem to recall that that discussion 
also revealed that the version assumptions before that were quite 
inconsistent.  Code in PG12 and before makes references to OpenSSL as 
old as 0.9.6.  But OpenSSL 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 other changes to make it 
compile cleanly against OpenSSL 3.0.0.  Once that has survived some 
scrutiny from the buildfarm and also 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 disable deprecation 
warnings, and we may add some patches to that effect at some point, but 
it's not like OpenSSL 3.0.0 will be 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 matter if we write the 
wrapper or OpenSSL writes the wrapper.  Only OpenSSL has already written 
the wrapper and has created a well-defined way to declare that you want 
to use the wrapper, so I'd just take that.

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

> If they do, then that key will stop working with any OpenSSL 3 enabled software
> unless the legacy provider has been loaded.  My understanding is that users can
> load these in openssl.conf, so maybe it's mostly a documentation patch for us?

Yes, it looks like that should work, so no additional work required from us.

>> 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 look into changing the 
test driver setup so that it loads a custom openssl.cnf that loads the 
legacy providers.

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