On 2020-05-29 00:16, Daniel Gustafsson wrote:
> Regarding the deprecations, we can either set preprocessor directives or use
> compiler flags to silence the warning and do nothing (for now), or we could
> update to the new API. We probably want to different things for master vs
> back-branches, but as an illustration of what the latter could look like I've
> implemented this in 0001.
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.
> OpenSSL also deprecates DES keys in 3.0.0, which cause our password callback
> tests to fail with the cryptic error "fetch failed", as the test suite keys are
> encrypted with DES. 0002 fixes this by changing to AES256 (randomly chosen
> among the ciphers supported in 1.0.1+ and likely to be around), and could be
> applied already today as there is nothing 3.0.0 specific about it.
It appears you can load a "legacy provider" to support these keys. What
if someone made a key using 0.9.* with an older PostgreSQL version and
keeps using the same key? I'm wondering about the implications in
practice here. Obviously moving off legacy crypto is good in general.
There is also the question of what to do with the test suites in the
back branches.
Maybe we will want some user-exposed option about which providers to
load, since that also affects whether the FIPS provider gets loaded.
What's the plan there?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
