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

Greetings pgsql devs,

I would appreciate a review of my strategy for backporting the commits
related to CVE-2024-10978. (I am working with versions 11, 9.6, and 9.4,
for some older Debian releases.)

My conclusion is that of the two commits associated with CVE-2024-10978,
both are required in 11 and 9.6, but only one is required in 9.4.

I searched the list archives to see if there was a previous discussion
related to this and I found none. The only mention of CVE-2024-10978 was
the release announcement.

Details:

I started with the patches for version 12. These commits:
4c9d96f74ba4e7d01c086ca54f217e242dd65fae
c463338656ac47e5210fcf9fbf7d20efccce8de8

The log message for c463338656ac47e5210fcf9fbf7d20efccce8de8 includes
this bit:

----------
If cherry-picking the CVE-2024-10978 fixes, default to including this,
too.  (This fixes an unintended side effect of fixing CVE-2024-10978.)
----------

Having spent a fair amount of time working on these patches, I have
successfully backported them to 11 and 9.6, but I encountered a problem
with 9.4. After analyzing the changes, I believe that the regression
which c463338656ac47e5210fcf9fbf7d20efccce8de8 is intended to address
does not affect 9.4. The basis for this belief is that after observing
the failure of the new setconfig regression test during the build of
9.4, I backed all of 4c9d96f74ba4e7d01c086ca54f217e242dd65fae and the
non-test portion of c463338656ac47e5210fcf9fbf7d20efccce8de8,
re-executed the build and observed the same failure.

The failure I observed occurs in the pg_upgrade test, under the heading
"Performing Upgrade" in the output:

Restoring global objects in the new cluster
*failure*

The end of ./build/contrib/pg_upgrade/pg_upgrade_utility.log has the
following:

ALTER ROLE "sbuild" WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION;
ALTER ROLE
ALTER ROLE "regress_authenticated_user_sr" SET "role" TO 'regress_current_user';

This is the same failure in both cases for 9.4 (both CVE-2024-10978
commits applied, and neither applied).

Is it then correct to conclude the behavior which regressed in 9.6 and
newer as a result of 4c9d96f74ba4e7d01c086ca54f217e242dd65fae was
introduced after 9.4? And that hence in the case of backporting to 9.4
that c463338656ac47e5210fcf9fbf7d20efccce8de8 can be left out?

Regards,

-Roberto

-- 
Roberto C. Sánchez

On Sat, Dec 14, 2024 at 09:50:23PM -0500, Roberto C. Sánchez wrote:
> Greetings pgsql devs,
> 
> I would appreciate a review of my strategy for backporting the commits
> related to CVE-2024-10978. (I am working with versions 11, 9.6, and 9.4,
> for some older Debian releases.)
> 
> My conclusion is that of the two commits associated with CVE-2024-10978,
> both are required in 11 and 9.6, but only one is required in 9.4.
> 
I wonder if someone might be able to look at my original message and
help validate my analysis.

Regards,

-Roberto

-- 
Roberto C. Sánchez

On Mon, Dec 30, 2024 at 04:50:12PM -0500, Roberto C. Sánchez wrote:
> On Sat, Dec 14, 2024 at 09:50:23PM -0500, Roberto C. Sánchez wrote:
> > Greetings pgsql devs,
> > 
> > I would appreciate a review of my strategy for backporting the commits
> > related to CVE-2024-10978. (I am working with versions 11, 9.6, and 9.4,
> > for some older Debian releases.)
> > 
> > My conclusion is that of the two commits associated with CVE-2024-10978,
> > both are required in 11 and 9.6, but only one is required in 9.4.
> > 
> I wonder if someone might be able to look at my original message and
> help validate my analysis.

I saw your question and was kind of stumped about how to answer.  We
rarely look at back branches for backpatch analysis, so I think we are
kind of confused on how to answer.  Under what circumstances are you
supported versions of Postgres that we don't support?  Is this part of
Debian policy?  Is our five-year insufficient?


-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

Michael Paquier <michael@paquier.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

Hi Bruce,

On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
> On Mon, Dec 30, 2024 at 04:50:12PM -0500, Roberto C. Sánchez wrote:
> > On Sat, Dec 14, 2024 at 09:50:23PM -0500, Roberto C. Sánchez wrote:
> > > Greetings pgsql devs,
> > > 
> > > I would appreciate a review of my strategy for backporting the commits
> > > related to CVE-2024-10978. (I am working with versions 11, 9.6, and 9.4,
> > > for some older Debian releases.)
> > > 
> > > My conclusion is that of the two commits associated with CVE-2024-10978,
> > > both are required in 11 and 9.6, but only one is required in 9.4.
> > > 
> > I wonder if someone might be able to look at my original message and
> > help validate my analysis.
> 
> I saw your question and was kind of stumped about how to answer.  We
> rarely look at back branches for backpatch analysis, so I think we are
> kind of confused on how to answer.  Under what circumstances are you
> supported versions of Postgres that we don't support?  Is this part of
> Debian policy?  Is our five-year insufficient?
> 

Do you mean that branches for releases which are EOL are not looked at?
I understand that completely. What I was hoping for here was that
someone who was familiar with the old code might be able to look at my
analysis and either confirm that my conclusion is correct (the behavior
affected by the regression in the first commit was only introduced after
9.4) or not.

I did my best to structure my request in such a way that it would only
entail minimal effort to answer, assuming that it was viewed by someone
who had worked on those parts of the code that far back in the past.

As far as the five year support timeframe, that is amazing and much
more robust than many (most?) projects. Especially considering the size
and pace of development here. We do have a small (paid) team that tries
to support a specific subset of packages going back longer than 5 years.

If my request is not reasonable or somehow inappropriate, then please
consider it withdrawn.

Regards,

-Roberto

-- 
Roberto C. Sánchez

On Tue, Dec 31, 2024 at 10:23:29AM +0900, Michael Paquier wrote:
> On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
> > I saw your question and was kind of stumped about how to answer.  We
> > rarely look at back branches for backpatch analysis, so I think we are
> > kind of confused on how to answer.  Under what circumstances are you
> > supported versions of Postgres that we don't support?  Is this part of
> > Debian policy?
> 
> So am I (I'd say that you are on your own for this one, still..).
> It is the first time I hear about that on the lists, but perhaps
> Christoph Berg would know better?  Adding him in CC for comments. 
> 
> Applying patches to older branches is a speciality in itself, and
> requires a lot of work and analysis (not planning to do that here for
> this specific CVE).  The good thing is that 5a2fed911a85 has some
> regression tests, so you could be more confident that what you are
> doing is rather right.  Now the code in this area has changed slightly
> because of the introduction of parallel workers in 9.6, so that could
> be tricky.  I'd suggest to *not* bypass the work across multiple
> branches at once as it can help in dealing with conflicts in a more
> granular way, even if it may increase the analysis burden quite a bit.
> 
Ack. I worked my way one branch at a time, specifically for the reason
you cited.

> While on it, note also 73c9f91a1b6d by the way, which is a follow up
> of 5a2fed911a85 for CVE-2024-10978 related to parallel workers, it
> would not apply to 9.4, for sure.
> 
Definitely. That was relatively straightforward to figure out and
confirm.

Thanks for the hints.

Regards,

-Roberto

-- 
Roberto C. Sánchez

On Mon, Dec 30, 2024 at 10:02:18PM -0500, Roberto C. Sánchez wrote:
> Do you mean that branches for releases which are EOL are not looked at?
> I understand that completely. What I was hoping for here was that
> someone who was familiar with the old code might be able to look at my
> analysis and either confirm that my conclusion is correct (the behavior
> affected by the regression in the first commit was only introduced after
> 9.4) or not.
> 
> I did my best to structure my request in such a way that it would only
> entail minimal effort to answer, assuming that it was viewed by someone
> who had worked on those parts of the code that far back in the past.

Agreed.

> As far as the five year support timeframe, that is amazing and much
> more robust than many (most?) projects. Especially considering the size
> and pace of development here. We do have a small (paid) team that tries
> to support a specific subset of packages going back longer than 5 years.
> 
> If my request is not reasonable or somehow inappropriate, then please
> consider it withdrawn.

I think it is good you are asking --- I just don't know if anyone can
help.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

On Mon, Dec 30, 2024 at 09:00:59PM -0500, Tom Lane wrote:
> 
> 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.  

I can't speak for RedHat, but on the Debian side we are actively pushing
back against this. It seems to be common practice for some corporate
outfits to manage compliance by running some commercially available
scanner and then trying to get every reported CVE "fixed" so that their
dashboard will be all green.

It's an uphill battle, though, since all-green dashboards trump
rationality more often than not in those discussions.

> Meanwhile, even very critical
> data-loss bugs are typically ignored.  For a database, this verges
> on insanity.
> 

Ack.

> 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.
> 
As far as Debian and PostgreSQL, we try to avoid cherry-picking and opt
for the point releases you publish whenever possible. Christoph already
does this for the newer releases (what is present in Debian stable and
sometimes LTS, depending on how long it has been since the Debian LTS
version has been released). For the older releases, however, we are
sometimes dealing with PostgreSQL versions that are no longer actively
developed upstream, so we have to resort to cherry-picking.

It is definitely not ideal, but the PostgreSQL code is very high quality
and we are generally able to handle the backporting without the need of
exernal assistance.

In any event, if releases of 11, 9.6, and 9.4 were still being published
to address new security issues (and data integrity bugs), then we would
simply be using those. However, given the age of those releases, it is
understandable that such releases are no longer being made.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

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

Andrew Dunstan <andrew@dunslane.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

On Tue, Dec 31, 2024 at 07:36:23AM -0500, Andrew Dunstan wrote:
> On 2024-12-30 Mo 9:00 PM, Tom Lane wrote:
> > 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.

Ubuntu does LTS every two years but has three releases in between. 
Since we have yearly releases, an LTS every two years only cuts our
backpatches in half so it doesn't seem worth it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

On Tue, Dec 31, 2024 at 10:50:10AM +0100, Christoph Berg wrote:
> > 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.

Thanks, that was very helpful.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

On Tue, Dec 31, 2024 at 11:50:45AM -0500, Bruce Momjian wrote:
> On Tue, Dec 31, 2024 at 10:50:10AM +0100, Christoph Berg wrote:
> > > 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.
> 
> 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

On Tue, Dec 31, 2024 at 12:14:37PM -0500, Roberto C. Sánchez wrote:
> On Tue, Dec 31, 2024 at 11:50:45AM -0500, Bruce Momjian wrote:
> > On Tue, Dec 31, 2024 at 10:50:10AM +0100, Christoph Berg wrote:
> > > > 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.
> > 
> > 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.

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.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

On Tue, Dec 31, 2024 at 02:46:37PM -0500, Bruce Momjian wrote:
> 
> 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.
> 
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

On Tue, Dec 31, 2024 at 03:19:25PM -0500, Roberto C. Sánchez wrote:
> On Tue, Dec 31, 2024 at 02:46:37PM -0500, Bruce Momjian wrote:
> > 
> > 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.
> > 
> 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".

We don't normally ignore emails, so would not bother with a second
request.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

On Tue, Dec 31, 2024 at 01:47:19PM -0700, David G. Johnston wrote:
> On Tue, Dec 31, 2024 at 1:30 PM Bruce Momjian <bruce@momjian.us> wrote:
> 
>     On Tue, Dec 31, 2024 at 03:19:25PM -0500, Roberto C. Sánchez wrote:
> 
>     > 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".
> 
>     We don't normally ignore emails, so would not bother with a second
>     request.
> 
> 
> And yet the squeaky wheel does seem to get the grease; and I know from personal
> experience that emails will go unresponded two for weeks, which to a reasonable
> submitter to this list, when many responses are indeed the same day, seems like
> an email that got overlooked.

Yes, but we are explaining it was not overlooked, but rather no one
knows.  The odds of a reply are low, and the odds we just ignored it are
even lower.  If he does ask a second time for each backpatch, we are
likely to be even less motivated to help.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

On Tue, Dec 31, 2024 at 03:52:07PM -0500, Bruce Momjian wrote:
> On Tue, Dec 31, 2024 at 01:47:19PM -0700, David G. Johnston wrote:
> > On Tue, Dec 31, 2024 at 1:30 PM Bruce Momjian <bruce@momjian.us> wrote:
> > 
> >     On Tue, Dec 31, 2024 at 03:19:25PM -0500, Roberto C. Sánchez wrote:
> > 
> >     > 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".
> > 
> >     We don't normally ignore emails, so would not bother with a second
> >     request.
> > 
> > 
> > And yet the squeaky wheel does seem to get the grease; and I know from personal
> > experience that emails will go unresponded two for weeks, which to a reasonable
> > submitter to this list, when many responses are indeed the same day, seems like
> > an email that got overlooked.
> 
> Yes, but we are explaining it was not overlooked, but rather no one
> knows.  The odds of a reply are low, and the odds we just ignored it are
> even lower.  If he does ask a second time for each backpatch, we are
> likely to be even less motivated to help.

Actually, there is another concern.  Debian users who are using these 6+
year-old releases might think the release is supported by the community
and submit bug reports to us.  I can't remember anyone complaining when
we said a release was EOL by saying it is supported by Debian, so this is
probably a minor concern, but something to remember.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

On Wed, Jan 01, 2025 at 01:32:18PM -0500, Bruce Momjian wrote:
> 
> Actually, there is another concern.  Debian users who are using these 6+
> year-old releases might think the release is supported by the community
> and submit bug reports to us.  I can't remember anyone complaining when
> we said a release was EOL by saying it is supported by Debian, so this is
> probably a minor concern, but something to remember.
> 
And should a request arrive from someone on Debian using an older
unsupported release, then please direct them to
debian-lts@lists.debian.org.

Regards,

-Roberto

-- 
Roberto C. Sánchez

On Wed, Jan  1, 2025 at 08:43:40PM -0500, Roberto C. Sánchez wrote:
> On Wed, Jan 01, 2025 at 01:32:18PM -0500, Bruce Momjian wrote:
> > 
> > Actually, there is another concern.  Debian users who are using these 6+
> > year-old releases might think the release is supported by the community
> > and submit bug reports to us.  I can't remember anyone complaining when
> > we said a release was EOL by saying it is supported by Debian, so this is
> > probably a minor concern, but something to remember.
> > 
> And should a request arrive from someone on Debian using an older
> unsupported release, then please direct them to
> debian-lts@lists.debian.org.

Good to know, thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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