Re: OpenSSL 3.0.0 compatibility

> On 29 May 2020, at 13:34, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> 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.

I think I know what you mean but just to clarify: I master, back-branches or
all of the above?

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.

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

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?

Iff key loading fails with an errormessage that indicates that the algorithm
couldn't be fetched (ie fetch failed), we could add an errhint on algorithm
use. Currently it's easy to believe that it's the key file that couldn't be
fetched, as the error message from OpenSSL is quite cryptic and expects the
user to understand OpenSSL terminology. This could happen already in pre-3
versions, so maybe it's worthwhile to do?

> 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+?

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

This again boils down to if we want to load providers, or if we want to punt
that to openssl.conf completely. Since we will support olders versions for a
long time still, maybe punting will render the cleanest code?

AFAICT, if care is taken with openssl.conf one could already load providers
such that postgres will operate in FIPS mode due to nothing non-FIPS being
available. For libpq I'm not sure if there is anything to do, as we don't
mandate any cipher use (SSL_CTX_set_cipher_list will simply fail IIUC). For
pgcrypto however it's another story, but there we'd need to rewrite it to not
use low-level APIs first since the use of those aren't FIPS compliant. Once
done, we could have an option for FIPS mode and pass the "fips=yes" property
when loading ciphers to make sure the right version is loaded if multiple ones
are available.

cheers ./daniel