|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
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?
|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|