Re: OpenSSL 3.0.0 compatibility - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: OpenSSL 3.0.0 compatibility
Date
Msg-id 9CE70AF4-E1A0-4D24-86FA-4C3067077897@yesql.se
Whole thread Raw
In response to Re: OpenSSL 3.0.0 compatibility  (Michael Paquier <michael@paquier.xyz>)
Responses Re: OpenSSL 3.0.0 compatibility
Re: OpenSSL 3.0.0 compatibility
List pgsql-hackers
> On 17 Aug 2020, at 06:12, Michael Paquier <michael@paquier.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_logging_init() can return ENOTTY with TAP tests
Next
From: Tom Lane
Date:
Subject: XversionUpgrade tests broken by postfix operator removal