Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Дата
Msg-id Zg9Vv_FZ5WtOswnp@paquier.xyz
обсуждение исходный текст
Ответ на Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Jacob Champion <jacob.champion@enterprisedb.com>)
Ответы Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Mikael Kjellström <mikael.kjellstrom@mksoft.nu>)
Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Jacob Champion <jacob.champion@enterprisedb.com>)
Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
(Adding Mikael Kjellstrom in CC as OpenBSD owner)

On Thu, Apr 04, 2024 at 11:03:35AM -0700, Jacob Champion wrote:
> v3 does that by putting back checks for symbols that aren't part of
> LibreSSL (tested back to 2.7, which is where the 1.1.x APIs started to
> arrive).

From where did you pull the LibreSSL sources?  Directly from the
OpenBSD tree?

> It also makes adjustments for the new OPENSSL_API_COMPAT
> version, getting rid of OpenSSL_add_all_algorithms() and adding a
> missing header.

Ah, right.  OpenSSL_add_all_algorithms() is documented as having no
effect in 1.1.0.

> This patch has a deficiency where 1.1.0 itself isn't actually rejected
> at configure time; Daniel's working on an explicit check for the
> OPENSSL/LIBRESSL_VERSION_NUMBER that should fix that up. There's an
> open question about which version we should pin for LibreSSL, which
> should ultimately come down to which versions of OpenBSD we want PG17
> to support.

I would be OK to draw a line to what we test in the buildfarm if it
comes to that, down to OpenBSD 6.9.  This version is already not
supported, and we had a number of issues with older versions and
timestamps going backwards.

-/* Define to 1 if you have the `CRYPTO_lock' function. */
-#undef HAVE_CRYPTO_LOCK

I'm happy to see that gone for good.

+      # Functions introduced in OpenSSL 1.1.0/LibreSSL 2.7.0.
+      ['OPENSSL_init_ssl', {'required': true}],
+      ['BIO_meth_new', {'required': true}],
+      ['ASN1_STRING_get0_data', {'required': true}],
+      ['HMAC_CTX_new', {'required': true}],
+      ['HMAC_CTX_free', {'required': true}],

These should be removed to save cycles in ./configure and meson, no?
We don't have any more of their HAVE_* flags in the tree with this
patch applied.

-      cdata.set('OPENSSL_API_COMPAT', '0x10002000L',
+      cdata.set('OPENSSL_API_COMPAT', '0x10100000L',

Seems to me that this should also document in meson.build why 1.1.0 is
chosen, same as ./configure.

It seems to me that src/common/protocol_openssl.c could be cleaned up;
I see SSL_CTX_set_min_proto_version and SSL_CTX_set_max_proto_version
listed in LibreSSL (looking at some past version of
https://github.com/libressl/libressl.git that I still have around).

There is an extra thing in pg_strong_random.c once we cut OpenSSL <
1.1.1..  Do we still need pg_strong_random_init() and its RAND_poll()
when it comes to LibreSSL?  This is a sensitive area, so we should be
careful.
--
Michael

Вложения

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

Предыдущее
От: Corey Huinker
Дата:
Сообщение: Re: Statistics Import and Export
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: IPC::Run::time[r|out] vs our TAP tests