Re: Security lessons from liblzma - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Security lessons from liblzma
Date
Msg-id 220e5d5b-e5b2-4d20-af0a-f3e656496557@joeconway.com
Whole thread Raw
In response to Re: Security lessons from liblzma  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Security lessons from liblzma
List pgsql-hackers
On 3/31/24 11:49, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> I am saying maybe those patches should be eliminated in favor of our 
>> tree including build options that would produce the same result.
> 
> I don't really see how that can be expected to work sanely.
> It turns the responsibility for platform-specific build issues
> on its head, and it doesn't work at all for issues discovered
> after we make a release.  The normal understanding of how you
> can vet a distro's package is that you look at the package
> contents (the SRPM in Red Hat world and whatever the equivalent
> concept is elsewhere), check that the contained tarball
> matches upstream and that the patches and build instructions
> look sane, and then build it locally and check for a match to
> the distro's binary package.  Even if we could overcome the
> obstacles to putting the patch files into the upstream tarball,
> we're surely not going to include the build instructions, so
> we'd not have moved the needle very far in terms of whether the
> packager could do something malicious.

True enough I guess.

But it has always bothered me how many patches get applied to the 
upstream tarballs by the OS package builders. Some of them, e.g. glibc 
on RHEL 7, include more than 1000 patches that you would have to 
manually vet if you cared enough and had the skills. Last time I looked 
at the openssl package sources it was similar in volume and complexity. 
They might as well be called forks if everyone were being honest about it...

I know our PGDG packages are no big deal compared to that, fortunately.

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com




pgsql-hackers by date:

Previous
From: Devrim Gündüz
Date:
Subject: Re: Security lessons from liblzma
Next
From: Tom Lane
Date:
Subject: Re: Statistics Import and Export