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