Date: Mon, 30 Dec 2024 22:27:28 -0500
From: Roberto =?iso-8859-1?Q?C=2E_S=E1nchez?= <roberto@debian.org>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6,
 and 9.4)
Message-ID: <Z3NkoNLhKWKvbv1S@localhost>
References: <Z15D7-HHXweXI2so@localhost>
 <Z3MVlEHp3yNutuHH@localhost>
 <Z3MXgpG64kYxefiG@momjian.us>
 <Z3NHkW31MfTaV9u1@paquier.xyz>
 <3999105.1735610459@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3999105.1735610459@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/Z3NkoNLhKWKvbv1S%40localhost>
Precedence: bulk

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