Re: Security lessons from liblzma

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Banck <mbanck(at)gmx(dot)net>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Security lessons from liblzma
Date: 2024-03-31 19:27:47
Message-ID: 796017.1711913267@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Banck <mbanck(at)gmx(dot)net> writes:
> On Sun, Mar 31, 2024 at 01:05:40PM -0400, Joe Conway wrote:
>> But it has always bothered me how many patches get applied to the upstream
>> tarballs by the OS package builders.

> I think this more an artifact of how RHEL development works, i.e. trying
> to ship the same major version of glibc for 10 years, but still fix lots
> of bugs and possibly some performance improvements your larger customers
> ask for. So I guess a lot of those 1000 patches are just cherry-picks /
> backports of upstream commits from newer releases.

Yeah. Also, precisely because they keep supporting versions that are
out-of-support according to upstream, the idea that all the patches
can be moved upstream isn't going to work for them, and they're
unlikely to be excited about partial solutions.

The bigger problem though is: if we do this, are we going to take
patches that we fundamentally don't agree with? For instance,
if a packager chooses to rip out the don't-run-server-as-root check.
(Pretty sure I've heard of people doing that.) That would look like
blessing things we don't think are good ideas, and it would inevitably
lead to long arguments with packagers about why-dont-you-do-this-some-
other-way. I'm not excited about that prospect.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-03-31 21:12:57 Re: Security lessons from liblzma
Previous Message Tom Lane 2024-03-31 19:15:01 Re: Add column name to error description