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.
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
