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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, mikael(dot)kjellstrom(at)gmail(dot)com
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Date: 2024-04-05 01:37:03
Message-ID: Zg9Vv_FZ5WtOswnp@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-04-05 02:12:18 Re: IPC::Run::time[r|out] vs our TAP tests
Previous Message Corey Huinker 2024-04-05 01:30:32 Re: Statistics Import and Export