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

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 2024-12-30 Mo 9:00 PM, Tom Lane wrote:
>> 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 is only a handwavy idea so far, but what I was imagining would
basically just be changes in policy about which fixes get put into
which branches. I doubt that we'd need new infrastructure mechanisms.

One problem with the idea is that (as already mentioned upthread)
it's wise to back-patch one branch at a time, if only to quantize
the changes you're dealing with as much as possible. So if we were
to say that, say, v13 is LTS but v14 and v15 are dead, people would
likely still prepare and test patches against v15 and v14 on the
way to fixing v13. It seems a bit silly to throw away that work,
and sillier to not let the buildfarm test it. So that leads to the
conclusion that we're still committing into everything back to the
oldest supported-at-all branch. We could skip the formal release
work for intermediate branches, but that saves very little.

So, having slept on it, the only part of the idea that really seems
workable is to declare that older branches are in "LTS" rather than
full support for some period of time, and have a very narrow
definition of which bugs are candidates to be fixed in LTS branches
(in order to keep the workload manageable). This isn't an entirely
new concept: we already have a policy about fixing build failures
further back than the full-support branches. Still, it'd add
complication to committers' lives, and I think we'd need to shorten
the full-support window to keep our workload from getting out of hand.

So I don't know how attractive this idea is overall. Maybe something
to kick around at the next developers meeting?

regards, tom lane