agora inbox for [email protected]
help / color / mirror / Atom feedFrom: Roberto C. Sánchez <[email protected]>
To: [email protected]
Subject: Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)
Date: Mon, 30 Dec 2024 22:27:28 -0500
Message-ID: <Z3NkoNLhKWKvbv1S@localhost> (raw)
In-Reply-To: <[email protected]>
References: <Z15D7-HHXweXI2so@localhost>
<Z3MVlEHp3yNutuHH@localhost>
<[email protected]>
<[email protected]>
<[email protected]>
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
view thread (13+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)
In-Reply-To: <Z3NkoNLhKWKvbv1S@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox