Horton

Thread

  1. Re: PostgreSQL and OpenSSL 4.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-07T13:44:45Z

    > 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

  2. Re: PostgreSQL and OpenSSL 4.0.0

    Cary Huang <cary.huang@highgo.ca> — 2026-05-07T19:32:51Z

    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

  3. Re: PostgreSQL and OpenSSL 4.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-07T19:39:44Z

    > 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

  4. Re: PostgreSQL and OpenSSL 4.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-07T19:51:50Z

    > 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

  5. Re: PostgreSQL and OpenSSL 4.0.0

    Michael Paquier <michael@paquier.xyz> — 2026-05-07T22:13:05Z

    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

  6. Re: PostgreSQL and OpenSSL 4.0.0

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-07T22:22:14Z

    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

  7. Re: PostgreSQL and OpenSSL 4.0.0

    Cary Huang <cary.huang@highgo.ca> — 2026-05-07T22:54:24Z

    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

  8. Re: PostgreSQL and OpenSSL 4.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-08T07:07:41Z

    > 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

  9. Re: PostgreSQL and OpenSSL 4.0.0

    Michael Paquier <michael@paquier.xyz> — 2026-05-08T07:17:32Z

    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

  10. Re: PostgreSQL and OpenSSL 4.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-08T07:21:25Z

    > 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

  11. Re: PostgreSQL and OpenSSL 4.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-19T21:18:08Z

    > On 8 May 2026, at 00:21, Daniel Gustafsson <daniel@yesql.se> wrote:

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

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

--
Daniel Gustafsson

  12. Re: PostgreSQL and OpenSSL 4.0.0

    Michael Paquier <michael@paquier.xyz> — 2026-05-26T06:02:50Z

    On Tue, May 19, 2026 at 02:18:08PM -0700, Daniel Gustafsson wrote:
> > On 8 May 2026, at 00:21, Daniel Gustafsson <daniel@yesql.se> wrote:
> 
> > 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.
> 
> 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

  13. Re: PostgreSQL and OpenSSL 4.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-26T08:16:40Z

    > On 26 May 2026, at 08:02, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Tue, May 19, 2026 at 02:18:08PM -0700, Daniel Gustafsson wrote:
>>> On 8 May 2026, at 00:21, Daniel Gustafsson <daniel@yesql.se> wrote:
>> 
>>> 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.
>> 
>> 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.

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

  14. Re: PostgreSQL and OpenSSL 4.0.0

    Michael Paquier <michael@paquier.xyz> — 2026-05-27T00:06:01Z

    On Tue, May 26, 2026 at 10:16:40AM +0200, Daniel Gustafsson wrote:
> I have plans for fixing this in v20 but for 14-19 there isn't much we can do
> except unconstifying.

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

  15. Re: PostgreSQL and OpenSSL 4.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-27T10:47:32Z

    > On 27 May 2026, at 02:06, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Tue, May 26, 2026 at 10:16:40AM +0200, Daniel Gustafsson wrote:
>> I have plans for fixing this in v20 but for 14-19 there isn't much we can do
>> except unconstifying.
> 
> 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
> OpenSSL supported should make the situation much saner, even if the
> range of changes seems to be limited due to the LibreSSL story.

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

  16. Re: PostgreSQL and OpenSSL 4.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-29T20:05:56Z

    > On 27 May 2026, at 12:47, Daniel Gustafsson <daniel@yesql.se> wrote:
> 
>> On 27 May 2026, at 02:06, Michael Paquier <michael@paquier.xyz> wrote:
>> 
>> On Tue, May 26, 2026 at 10:16:40AM +0200, Daniel Gustafsson wrote:
>>> I have plans for fixing this in v20 but for 14-19 there isn't much we can do
>>> except unconstifying.
>> 
>> 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.

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