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

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
>> Is our five-year insufficient?

> FWIW, I'm already on the side that five-year support is quite good and
> I'd side with not extending that, even argue about reducing it
> (anti-tomato armor is now on). Backporting patches across up to 7
> branches can be really tedious depending on what you are dealing with
> in the backend.

Yeah, I can't see extending it, at least not under our current theory
of back-patching (nearly) every bug fix to all supported branches.
Could there be an intermediate state where older branches get only
"critical" fixes? (Security and data-loss bugs only, IMV.) Another
not-necessarily-exclusive idea is to designate only certain branches
as LTS. We could free up the developer bandwidth needed for LTS
by shortening the period in which non-LTS branches get full support.

This ties into a criticism I have of the criteria that outfits like
Debian and Red Hat seem to have for back-patching bug fixes: if it's
labeled "CVE" then it must get fixed, even for something as narrow
and low-impact as CVE-2024-10978. Meanwhile, even very critical
data-loss bugs are typically ignored. For a database, this verges
on insanity.

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.

regards, tom lane