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

On 2024-12-30 Mo 9:00 PM, Tom Lane wrote:
> 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.

How would that work? Something like even numbered branches are LTS and
odd numbered branches would expire after two years instead of five?
Trying to get my head around what if any buildfarm changes that might
require. Probably just adjust how we manage branches_of_interest.txt,
but maybe there's something I haven't thought of.

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

Yeah, we'd need to get some buyin from the major downstream distributors.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com