Re: Security lessons from liblzma
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Banck <mbanck@gmx.net>
Cc: Joe Conway <mail@joeconway.com>, Bruce Momjian <bruce@momjian.us>,
Andres Freund <andres@anarazel.de>,
Robert Haas <robertmhaas@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-03-31T19:27:47Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Introduce a non-recursive JSON parser
- 3311ea86edc7 17.0 cited
Michael Banck <mbanck@gmx.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