Re: Security lessons from liblzma

From: Joe Conway <mail(at)joeconway(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Security lessons from liblzma
Date: 2024-03-30 23:54:00
Message-ID: 686adb18-be22-4704-8168-a7fcb97b8fda@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/30/24 17:12, Andres Freund wrote:
> Hi,
>
> On 2024-03-30 16:50:26 -0400, Robert Haas wrote:
>> We might also want to move toward signing commits and tags. One of the
>> meson maintainers was recommending that on-list not long ago.
>
> I don't know how valuable the commit signing really is, but I strongly agree
> that we should sign both tags and tarballs.

+1

>> We should think about weaknesses that might occur during the packaging
>> process, too. If someone who alleges that their packaging PG is really
>> packaging PG w/badstuff123.patch, how would we catch that?
>
> I don't think we realistically can. The environment, configure and compiler
> options will influence things too much to do any sort of automatic
> verification.
>
> But that shouldn't stop us from ensuring that at least the packages
> distributed via *.postgresql.org are reproducibly built.
>
> Another good avenue for introducing an attack would be to propose some distro
> specific changes to the packaging teams - there's a lot fewer eyes there. I
> think it might be worth working with some of our packagers to integrate more
> of their changes into our tree.

Huge +1 to that. I have thought many times, and even said to Devrim, a
huge number of people trust him to not be evil.

Virtually every RPM source, including ours, contains out of tree patches
that get applied on top of the release tarball. At least for the PGDG
packages, it would be nice to integrate them into our git repo as build
options or whatever so that the packages could be built without any
patches applied to it. Add a tarball that is signed and traceable back
to the git tag, and we would be in a much better place than we are now.

>> I can't for example verify what the infrastructure team is doing,

Not sure what you feel like you should be able to follow -- anything
specific?

>> or what Tom does when he builds the release tarballs.

Tom follows this, at least last time I checked:

https://wiki.postgresql.org/wiki/Release_process

> This one however, I think we could improve upon. Making sure the tarball
> generation is completely binary reproducible and providing means of checking
> that would surely help. This will be a lot easier if we, as dicussed
> elsewhere, I believe, split out the generated docs into a separately
> downloadable archive. We already stopped including other generated files
> recently.

again, big +1

>> We shouldn't make the mistake of assuming that bad things can't happen to
>> us.
>
> +1

and again with the +1 ;-)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2024-03-31 00:05:59 Re: Security lessons from liblzma
Previous Message Thomas Munro 2024-03-30 23:49:36 Re: broken JIT support on Fedora 40