Re: OpenSSL 3.0.0 compatibility

> On 22 Sep 2020, at 14:01, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
>> On 22 Sep 2020, at 11:37, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>>
>> On 2020-09-18 16:11, Daniel Gustafsson wrote:
>>> Since we support ciphers that are now deprecated, we have no other choice than
>>> to load the legacy provider.
>>
>> Well, we could just have deprecated ciphers fail, unless the user loads the legacy provider in the OS configuration. There might be an argument that that is more proper.
>
> Thats a fair point. The issue I have with that is that we'd impose a system
> wide loading of the legacy provider, impacting other consumers of libssl as
> well.

After another round of thinking on this, somewhat spurred on by findings in the
the nearby FIPS thread, I'm coming around to this idea.

Looking at SCRAM+FIPS made me realize that we can't enforce FIPS mode in
pgcrypto via the OpenSSL configuration file, since pgcrypto doesn't load the
config. The automatic initialization in 1.1.0+ will however load the config
file, so not doing it for older versions makes pgcrypto inconsistent. Thus, I
think we should make sure that pgcrypto loads the configuratio for all OpenSSL
versions, and defer the provider decision in 3.0.0 to the users. This makes
the patch minimally intrusive while making pgcrypto behave consistently (and
giving 3.0.0 users the option to not run legacy).

The attached adds config loading to pgcrypto for < 1.1.0 and a doc notice for
enabling the legacy provider in 3.0.0. This will require an alternative output
file for non-legacy configs, but that should wait until 3.0.0 is GA since the
returned error messages have changed over course of development and may not be
set in stone just yet.

cheers ./daniel