Re: Remove deprecation warnings when compiling PG ~13 with OpenSSL 3.0~ - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Remove deprecation warnings when compiling PG ~13 with OpenSSL 3.0~
Date
Msg-id ZJONe8drp672DOGw@paquier.xyz
Whole thread Raw
In response to Re: Remove deprecation warnings when compiling PG ~13 with OpenSSL 3.0~  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Remove deprecation warnings when compiling PG ~13 with OpenSSL 3.0~  (Daniel Gustafsson <daniel@yesql.se>)
Re: Remove deprecation warnings when compiling PG ~13 with OpenSSL 3.0~  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
On Wed, Jun 21, 2023 at 10:11:33AM +0200, Peter Eisentraut wrote:
> Backpatching the OPENSSL_API_COMPAT change would set the minimum OpenSSL
> version to 1.0.1, which is newer than what was so far required in those
> branches.  That is the reason we didn't do this.

Looking at the relevant thread from 2020, this was still at the point
where we did not consider supporting 3.0 for all the stable branches
because 3.0 was in alpha:
https://www.postgresql.org/message-id/3d4afcfc-0930-1389-b9f7-59bdf11fb125@2ndquadrant.com

However, recent fixes like cab553a have made that possible, and we do
build with OpenSSL 3.0 across the whole set of stable branches.
Regarding the versions of OpenSSL supported:
- REL_13_STABLE requires 1.0.1 since 7b283d0e1.
- REL_12_STABLE and REL_11_STABLE require 0.9.8.

For 0.9.8, OPENSSL_API_COMPAT needs to be set at 0x00908000L (see
upstream's CHANGES.md).  So I don't see a reason not to do as
suggested by Andres?

I have tested the attached patches across 11~13 with various versions
of OpenSSL (OPENSSL_API_COMPAT exists since 1.1.0), and this is
working here.  Note that I don't have a MSVC environment at hand to
test this change on Windows, still `perl -cw Solution.pm` is OK with
it.

What do you think about the attached patch set (one for each branch)?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: ProcessStartupPacket(): database_name and user_name truncation
Next
From: Peter Geoghegan
Date:
Subject: Re: Adding further hardening to nbtree page deletion