Re: OpenSSL 3.0.0 compatibility

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: OpenSSL 3.0.0 compatibility
Date: 2020-07-07 20:52:47
Message-ID: 2F563A2D-5216-4044-8C38-A09E617F9728@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 7 Jul 2020, at 19:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>> Trying to move this along,

Thanks, this has stalled a bit on my TODO.

>> where would be a good place to define
>> OPENSSL_API_COMPAT? The only place that's shared between frontend and
>> backend code is c.h. The attached patch does it that way.
>
> pg_config_manual.h, perhaps?

I don't have a strong preference. When starting hacking on this I went for the
quick and simple option of adding it to CFLAGS in configure.in for the time
being since I wasn't sure where to put it.

A slightly more complicated problem arise when trying to run the pgcrypto
regress tests, and make it run the tests for the now deprecated ciphers, as
they require the legacy provider to be loaded via the openssl configuration
file. As was mentioned upthread, this requires us to inject our own
openssl.cnf in OPENSSL_CONF, load the legacy provider there and then from that
file include the system openssl.cnf (or override the system one completely
during testing which doesn't seem like a good idea).

Hacking this up in a crude PoC I added a REGRESS_ENV option in pgxs.mk which
then pgcrypto/Makefile could use to set an OPENSSL_CONF, which in turn ends
with a .include=<path> for my system config. This enables pgcrypto to load
the now deprecated ciphers, but even as PoC's goes this is awfully brittle and
a significant amount of bricks shy.

Actually running the tests with the legacy provider loaded yields a fair number
of errors like these, and somewhere around there I ran out of time for now as
the CF started.

- decrypt
-----------------------------
- Lets try a longer message.
+ decrypt
+----------------------------------------------------------
+ Lets try a longer messag\177\177\177\177\177\177\177\177

Memorizing the "cannot load cipher" errors in an alternative output and
documenting how to use old ciphers in pgcrypto together with OpenSSL 3.0.0+
might be the least bad option? Anyone else have any good ideas on how to get
this into the testrunner?

cheers ./daniel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-07-07 20:53:00 Re: Default setting for enable_hashagg_disk (hash_mem)
Previous Message Peter Geoghegan 2020-07-07 20:37:15 Re: Default setting for enable_hashagg_disk (hash_mem)