Re: OpenSSL 3.0.0 compatibility

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: OpenSSL 3.0.0 compatibility
Дата
Msg-id 9CE70AF4-E1A0-4D24-86FA-4C3067077897@yesql.se
обсуждение исходный текст
Ответ на Re: OpenSSL 3.0.0 compatibility  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: OpenSSL 3.0.0 compatibility
Re: OpenSSL 3.0.0 compatibility
Список 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




Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_logging_init() can return ENOTTY with TAP tests
Следующее
От: Tom Lane
Дата:
Сообщение: XversionUpgrade tests broken by postfix operator removal