> On 8 May 2026, at 00:22, Tom Lane <[email protected]> wrote: > > Michael Paquier <[email protected]> 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
