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

Re: Michael Paquier
> > 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.

For context, there is several levels of "supported" in Debian. The
stable release of course has security support. When a new stable is
released (approximately every 2 years), the old stable gets renamed to
"oldstable" which is then still supported by the Debian security team
for one more year.

Once that is over, the suite gets picked up by the LTS team which
supports that release for a total of 5 years:

https://wiki.debian.org/LTS/

So for this part, the release lifetime of Debian matches that of
PostgreSQL and there is no gap (perhaps with some months missing
towards the very end).

On top of that, there is a commercially-managed effort by community
members to extend that to 10 years, Extended LTS:

https://wiki.debian.org/LTS/Extended

(I am not involved in ELTS, though we do talk to each other of course.)


Re: Tom Lane
> 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.)

That would certainly help ELTS-like efforts to decide which bits to
grab.

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

I imagine "syncing" these branches with downstream's release cycles
would be tricky. If every other branch would be labeled as LTS, it
would have to match Debian's 2-year cycle (and there are other
distributions). If the cycle were longer, the support window would
probably be have to be much larger for it to make sense and Debian
will have to pick the LTS branch for release even when there's a
newer one.

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

AFAICT CVEs are already picked based on severity, though the criticism
probably holds for the bug fix, but...

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

Christoph