Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4) - Mailing list pgsql-hackers

From Roberto C. Sánchez
Subject Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)
Date
Msg-id Z3QmfWj8kmA2aFvI@localhost
Whole thread Raw
In response to Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)
List pgsql-hackers
On Tue, Dec 31, 2024 at 11:50:45AM -0500, Bruce Momjian wrote:
> On Tue, Dec 31, 2024 at 10:50:10AM +0100, Christoph Berg wrote:
> > > Maybe, if we were doing an only-critical-fixes LTS release series,
> > > it'd be easier for downstream outfits to consume that instead of
> > > cherry-picking security fixes.  I'm just speculating though.
> > > It's entirely possible that packagers would ignore our opinions
> > > and keep on cherry-picking only security fixes, in which case
> > > we'd be doing a lot of work for little return.
> > 
> > ... if there were a PostgreSQL LTS series, Debian would probably use it.
> > 
> > Overall, I think the current 5-year support window is good enough.
> > I don't see PostgreSQL supporting 10 years, so ELTS efforts will
> > always have to do some patching on their own.
> 
> Thanks, that was very helpful.
> 
I'd like to ask something, for future reference.

Should the ELTS team not make requests like the one I made here
initially?

In other words, I am trying to understand if the 5 year support window
means "this branch is no longer actively supported" or "no longer
actively supported, and we do not want questions/discussions about it on
this list".

If the latter, then I will document this to ensure that we respect this
boundary.

Regards,

-Roberto

-- 
Roberto C. Sánchez



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Add XMLNamespaces to XMLElement
Next
From: Sami Imseih
Date:
Subject: Re: add vacuum starttime columns