From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Mats Kindahl <mats@timescale.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: glibc qsort() vulnerability
In-reply-to: <20240206205305.GB3891538@nathanxps13>
References: <CA+14426g2Wa9QuUpmakwPxXFWG_1FaY0AsApkvcTBy-YfS6uaw@mail.gmail.com> <508821.1707232276@sss.pgh.pa.us> <20240206205305.GB3891538@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Tue, 06 Feb 2024 14:53:05 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <642083.1707252958.1@sss.pgh.pa.us>
Date: Tue, 06 Feb 2024 15:55:58 -0500
Message-ID: <642084.1707252958@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/642084.1707252958%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> Even if the glibc issue doesn't apply to Postgres, I'm tempted to suggest
> that we make it project policy that comparison functions must be
> transitive.  There might be no real issues today, but if we write all
> comparison functions the way Mats is suggesting, it should be easier to
> reason about overflow risks.

A comparison routine that is not is probably broken, agreed.
I didn't look through the details of the patch --- I was more
curious whether we had a version of the qsort bug, because
if we do, we should fix that too.

			regards, tom lane