Subject: PostgreSQL and OpenSSL 4.0.0

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 16 Apr 2026 15:32:54 +0200

With OpenSSL 4.0.0 shipping GA a few days ago I tried compiling PostgreSQL
against it and run the tests.  Unsurpisingly the test pass just fine and it
compiles without error since they aren't removing any API's we use (they are
deprecating more APIs we use, more on that in later threads).  There are
however a number of warnings since they changed constness on a number of API's.
Sadly, just adopting const cause similar warnings on OpenSSL 1.1.1 and LibreSSL
so we need to do uglier tricks with casting away constness.

The attached patch, while not pretty, allows libpq and sslinfo to build without
warnings on OpenSSL 1.1.1 through 4.0.0 as well as on LibreSSL (and there is
quite some variability in constness across all these API versions).

--
Daniel Gustafsson

---

From: Michael Paquier <[email-masked]>
Date: Sat, 18 Apr 2026 06:50:57 +0900

> quite some variability in constness across all these API versions).

Thanks for that.  That is super fast.

This is likely going to require a backpatch at some point, right?
What's the impact of the blast in branches where we need to support
OpenSSL down to 1.0.1, which is the minimum version in REL_14_STABLE?
--
Michael

---

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 7 May 2026 15:44:45 +0200

> On 17 Apr 2026, at 23:50, Michael Paquier <[email-masked]> wrote:
> 

Indeed, we probably want to backpatch this at some point since OpenSSL 4 is
equally likely to be used regardless of which branch users compile.  Whether we
want to apply this already before 19 goes beta I'll leave for the RMT to
decide.

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.

--
Daniel Gustafsson

---

From: Cary Huang <[email-masked]>
Date: Thu, 07 May 2026 12:32:51 -0700

Hi

I tried the patch and Postgres and sslinfo compiled with no warnings as
expected.

However, in OpenSSL 4.0, I noticed that it reports certificate revocation
errors differently from previous versions, causing the SSL tests to fail.
The test expects "ssl alert certificate revoked", but OpenSSL 4.0 returns
"tls alert certificate revoked" instead.

I made a patch to make the ssl tests compatible with OpenSSL 4.0 as well.

thanks!

Cary Huang
-------------
HighGo Software Inc. (Canada)
[email-masked]
www.highgo.ca

---

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 7 May 2026 21:39:44 +0200

> On 7 May 2026, at 21:32, Cary Huang <[email-masked]> wrote:

> I tried the patch and Postgres and sslinfo compiled with no warnings as

Thanks for looking!

> "tls alert certificate revoked" instead.

Which version of the patch did you try?  I thought I had fixed that in the
patchset I posted earlier today but perhaps I missed some parts.

--
Daniel Gustafsson

---

From: Daniel Gustafsson <[email-masked]>
Date: Thu, 7 May 2026 21:51:50 +0200

> On 7 May 2026, at 15:44, Daniel Gustafsson <[email-masked]> wrote:

> all the supported versions of OpenSSL and LibreSSL.

On the topic of supported OpenSSL versions.

REL_14-REL_16 supports 1.0.1 (eol 9 years ago), REL_17 bumps that to 1.0.2 (eol
6 years ago) and starting with REL_18 we require 1.1.1 (eol ~2.5 years ago).
By the time we ship REL_19, 3.4 has a few weeks left in support and before 19.1
ships, 3.5 will be the oldest non-EOL version of OpenSSL.

--
Daniel Gustafsson

---

From: Michael Paquier <[email-masked]>
Date: Fri, 8 May 2026 07:13:05 +0900

> 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.
--
Michael

---

From: Tom Lane <[email-masked]>
Date: Thu, 07 May 2026 18:22:14 -0400

> these solutions are cool.

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.

			regards, tom lane

---

From: Cary Huang <[email-masked]>
Date: Thu, 07 May 2026 15:54:24 -0700

Hi

> patchset I posted earlier today but perhaps I missed some parts.

I tried the very first patch you shared. I see that the ssl test errors have
been addressed by the patches you shared after. So it is all good. I'll try
testing other test cases that may have used OpenSSL APIs.

thanks!

Cary Huang
-------------

---

From: Daniel Gustafsson <[email-masked]>
Date: Fri, 8 May 2026 09:07:41 +0200

> On 8 May 2026, at 00:22, Tom Lane <[email-masked]> wrote:
> 

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?

> 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

---

From: Michael Paquier <[email-masked]>
Date: Fri, 8 May 2026 16:17:32 +0900

> could of course make backpatching trickier if thats what you mean?

Argh.  I've misread you here, reading a "lowest" rather than
"highest".   Documenting that 3.6 is the highest version support on 
14-stable would also work here.  My apologies for the confusion.

If the patches for REL_14_STABLE to add support for 4.0 prove to be
low-risk while messing with 1.0.1, that would the best course of
action, of course.
--
Michael

---

From: Daniel Gustafsson <[email-masked]>
Date: Fri, 8 May 2026 09:21:25 +0200

> On 8 May 2026, at 09:17, Michael Paquier <[email-masked]> wrote:
> 

Ah, now it makes more sense =)

> low-risk while messing with 1.0.1, that would the best course of

I think the changes are straightforward enough that we can go ahead with them.
I'll re-test and re-post a new patchset for all branches once the minors ship.

--
Daniel Gustafsson

---

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 19 May 2026 14:18:08 -0700

> On 8 May 2026, at 00:21, Daniel Gustafsson <[email-masked]> wrote:

> I'll re-test and re-post a new patchset for all branches once the minors ship.

Attached are rebased versions of this patchset for v14-master.

--
Daniel Gustafsson

---

From: Michael Paquier <[email-masked]>
Date: Tue, 26 May 2026 15:02:50 +0900

> Attached are rebased versions of this patchset for v14-master.

I have a question here.  Most of the changes relate to the use of const
where the OpenSSL APIs require these to be so, but why is this a new
requirement for 4.0?  I can see that for most of the upstream
routines, the const changes are much older, like in 8cc86b81ac20 for
X509_NAME_get_text_by_NID() applying down to branch openssl-3.0.
--
Michael

---

From: Daniel Gustafsson <[email-masked]>
Date: Tue, 26 May 2026 10:16:40 +0200

> On 26 May 2026, at 08:02, Michael Paquier <[email-masked]> wrote:
> 

It is very true that OpenSSL has been constifying the API over time, the change
in 4.0 revolves around making more returnvalues const.  In the case at hand,
X509_get_subject_name() now returns a const X509_NAME pointer since commit
b0f2107b4404.  This wouldn't be a problem since X509_NAME_get_text_by_NID()
does as you say take a const parameter, but since we have shoehorned LibreSSL
support into the same file we are tied to the least common denominator and
LibreSSL is far behind OpenSSL on constifying.  So in this case, we need to
unconstify() to keep LibreSSL compiling.

I have plans for fixing this in v20 but for 14-19 there isn't much we can do
except unconstifying.

--
Daniel Gustafsson

---

From: Michael Paquier <[email-masked]>
Date: Wed, 27 May 2026 09:06:01 +0900

> I have plans for fixing this in v20 but for 14-19 there isn't much we can do

Indeed, no objections regarding that for the stable branches.  For
v20, it sounds to me that cutting through the set of versions of
OpenSSL supported should make the situation much saner, even if the
range of changes seems to be limited due to the LibreSSL story.
--
Michael

---

From: Daniel Gustafsson <[email-masked]>
Date: Wed, 27 May 2026 12:47:32 +0200

> On 27 May 2026, at 02:06, Michael Paquier <[email-masked]> wrote:
> 
> Indeed, no objections regarding that for the stable branches.

Thanks for confirming.  I am currently re-testing all the combinations of stable
postgres branches and supported OpenSSL and LibreSSL versions.

> For v20, it sounds to me that cutting through the set of versions of

Not to thread-jack myself, but.  I have a WIP patch for v20 which separates the
code into {fe|be}-secure-openssl.c and {fe[be}-secure-libressl such that we can
start modernizing our OpenSSL code without breaking LibreSSL or risk ending up
with an impenetrable ifdef soup.  Will share shortly to get a discussion going
for how we want to deal with TLS support in 20 and onwards.

--
Daniel Gustafsson

---

From: Daniel Gustafsson <[email-masked]>
Date: Fri, 29 May 2026 22:05:56 +0200

> On 27 May 2026, at 12:47, Daniel Gustafsson <[email-masked]> wrote:
> 

While I had hoped to get it done sooner (sickness altered my plans), I just
pushed this to master ahead of the beta1 deadline, and once it's been through
some rounds of buildfarm compiles I'll backpatch to the stable branches.

--
Daniel Gustafsson