Re: PostgreSQL and OpenSSL 4.0.0

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PostgreSQL and OpenSSL 4.0.0
Date: 2026-05-08 07:07:41
Message-ID: 1A5104C0-E9EF-4D90-9627-23D3D909104B@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 8 May 2026, at 00:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Michael Paquier <michael(at)paquier(dot)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.
>
>> 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.
>
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-05-08 07:09:46 Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column
Previous Message Alexander Korotkov 2026-05-08 06:39:09 Re: Fix bug with accessing to temporary tables of other sessions