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
