Re: OpenSSL 3.0.0 compatibility

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: OpenSSL 3.0.0 compatibility
Date: 2020-09-18 14:11:13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 17 Aug 2020, at 06:12, Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> Leaving the problems with pgcrypto aside for now

Returning to this subject, I decided to take a stab at fixing pgcrypto since it
wasn't working.

Since we support ciphers that are now deprecated, we have no other choice than
to load the legacy provider. The other problem was that the cipher context
padding must be explicitly set, whereas in previous versions relying on the
default worked fine. EVP_CIPHER_CTX_set_padding always returns 1 so thats why
it isn't checking the returnvalue as the other nearby initialization calls.
To avoid problems with the by LibreSSL overloaded OPENSSL_VERSION_NUMBER macro
(which too is deprecated in 3.0.0), I used the new macro which is only set in
3.0.0. Not sure if that's considered acceptable or if we should invent our own
version macro in autoconf.

For the main SSL tests, the incorrect password test has a new errormessage
which is added in 0002.

With these two all SSL tests pass for me in 1.0.1 through 3.0.0-alpha6 (tested
on a mix of Debian and macOS).

Thoughts on these?

cheers ./daniel

Attachment Content-Type Size
0002-Fix-ssl-tests-to-support-OpenSSL-3.0.0.patch application/octet-stream 1.2 KB
0001-Fix-pgcrypto-to-support-OpenSSL-3.0.0.patch application/octet-stream 3.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-09-18 14:39:10 XversionUpgrade tests broken by postfix operator removal
Previous Message Tom Lane 2020-09-18 13:56:14 Re: pg_logging_init() can return ENOTTY with TAP tests