PostgreSQL and OpenSSL 4.0.0

On Thu, Apr 16, 2026 at 03:32:54PM +0200, Daniel Gustafsson wrote:

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

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

On 17 Apr 2026, at 23:50, Michael Paquier <michael@paquier.xyz> wrote:

On Thu, Apr 16, 2026 at 03:32:54PM +0200, Daniel Gustafsson wrote:

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

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?

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

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)
cary.huang@highgo.ca
www.highgo.ca

On 7 May 2026, at 21:32, Cary Huang <cary.huang@highgo.ca> wrote:

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

Thanks for looking!

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.

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

On 7 May 2026, at 15:44, Daniel Gustafsson <daniel@yesql.se> wrote:

For 14 through master the attached compiles without warnings and tests green on
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

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

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.

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.

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

Hi

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.

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
-------------
HighGo Software Inc. (Canada)
cary.huang@highgo.ca
www.highgo.ca

On 8 May 2026, at 00:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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.

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

On Fri, May 08, 2026 at 09:07:41AM +0200, Daniel Gustafsson 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?

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

On 8 May 2026, at 09:17, Michael Paquier <michael@paquier.xyz> wrote:

On Fri, May 08, 2026 at 09:07:41AM +0200, Daniel Gustafsson 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?

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.

Ah, now it makes more sense =)

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.

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