> On 30 May 2020, at 11:29, Peter Eisentraut <peter.eisentr...@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 going forward. That declares our >>> intention, it will silence the deprecation warnings, and IIUC, if the >>> deprecated stuff actually gets 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.
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 version we 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 look into 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
