Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.2\))
Subject: Re: PostgreSQL and OpenSSL 4.0.0
From: Daniel Gustafsson <daniel@yesql.se>
In-Reply-To: <898414.1778192534@sss.pgh.pa.us>
Date: Fri, 8 May 2026 09:07:41 +0200
Cc: Michael Paquier <michael@paquier.xyz>,
 PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A5104C0-E9EF-4D90-9627-23D3D909104B@yesql.se>
References: <066B07BB-85FA-487C-BE8C-40F791CFC3C4@yesql.se>
 <aeKrQfeyDLVE3cmw@paquier.xyz>
 <65C5DC15-DE27-4D36-8AEE-A854C23B3834@yesql.se>
 <af0OcVKUaAMW1RaR@paquier.xyz> <898414.1778192534@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1A5104C0-E9EF-4D90-9627-23D3D909104B%40yesql.se>
Precedence: bulk

> On 8 May 2026, at 00:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> Michael Paquier <michael@paquier.xyz> writes:
>> On Thu, May 07, 2026 at 03:44:45PM +0200, Daniel Gustafsson wrote:
>>> For 14 through master the attached compiles without warnings and =
tests green on
>>> all the supported versions of OpenSSL and LibreSSL.  That being =
said, I'm not
>>> sure that we want to go all the way to 14 since if something does =
break, we
>>> can't really go around fixing it - I think amending the docs in 14 =
stating that
>>> OpenSSL 3.6 is the highest supported version is a better solution.
>=20
>> One issue with this approach is that any builds on these branches =
(say
>> REL_14_STABLE + OpenSSL 1.0.1) would be forced to either upgrade
>> OpenSSL to at least 3.6 for a minor Postgres update or give up on any
>> fix we can put on the 14 stable branch for six more months.  None of
>> these solutions are cool.

Not sure I follow, anyone still building with a X years out of support =
OpenSSL
will most likely keep doing so regardless of what CVE's are published.  =
It
could of course make backpatching trickier if thats what you mean?

> With one eye on the calendar, I think the right way to proceed is to
> push this to all branches (including 14) soon after next week's
> releases.  I feel this is too high-risk to shove in just before a
> release, but shortly after one is ideal since we'll have 3 months to
> find out any problems.
>=20
> I would support omitting 14 if we were down to just one remaining
> release for it, but we'll have 2 (August and November).  So there
> will still be an opportunity to fix things if there's an issue
> that manages to escape notice until after the August releases.

Doh..  thanks.  I was off-by-one and convinced myself we only have one =
more
minor on 14.  With two more scheduled I agree that we should go for =
OpenSSL 4
support in 14 as well.  I'll re-test and prep all the branches with all =
the
version of OpenSSL so that I can get this in shortly after the next =
weeks
releases go out.

--
Daniel Gustafsson