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

From: Christoph Berg <[email-masked]>
Date: Tue, 31 Dec 2024 10:50:10 +0100

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

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 31 Dec 2024 11:50:45 -0500

> always have to do some patching on their own.

Thanks, that was very helpful.

-- 
  Bruce Momjian  <[email-masked]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

---

From: Roberto C. Sánchez <[email-masked]>
Date: Tue, 31 Dec 2024 12:14:37 -0500

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 31 Dec 2024 14:46:37 -0500

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

Good question.  In a way, if the person who made the change sees your
request and can answer it easily, it makes sense to ask.  However, I
don't know the odds of that happening.

I would say ask, but don't take it personally if it your request is
ignored.  We have fatigue about all the backpatching we have to do so it
is hard to get motivated enough to research EOL branches.

---

From: Roberto C. Sánchez <[email-masked]>
Date: Tue, 31 Dec 2024 15:19:25 -0500

> is hard to get motivated enough to research EOL branches.
That's helpful feedback.

I definitely didn't take it personally this time and won't in the future
either.

My thinking was "ask once, bump the thread once after 2 or 3 weeks just
in case it got lost in the noise (this is a busy list), and after that
let the matter rest if there is no answer".

Regards,

-Roberto

-- 
Roberto C. Sánchez