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

From Tom Lane
Subject Re: Security lessons from liblzma
Date
Msg-id 584074.1711844145@sss.pgh.pa.us
Whole thread Raw
In response to Re: Security lessons from liblzma  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> On 3/30/24 19:54, Joe Conway wrote:
>> Tom follows this, at least last time I checked:
>> https://wiki.postgresql.org/wiki/Release_process

> Reading through that, I wonder if this part is true anymore:

>    In principle this could be done anywhere, but again there's a concern
>    about reproducibility, since the results may vary depending on
>    installed bison, flex, docbook, etc versions. Current practice is to
>    always do this as pgsql on borka.postgresql.org, so it can only be
>    done by people who have a login there. In detail:

The reproducibility argument would still apply to the docs (in
whatever form we're packaging them), but hopefully not to the
basic source tarball.

> Maybe if we split out the docs from the release tarball, we could also 
> add the script (mk-release) to our git repo?

If memory serves, the critical steps are already in our source tree,
as "make dist" (but I'm not sure how that's going to work if we want
to get away from using autoconf/make).  It's not clear to me how much
of the rest of mk-release is relevant to people who might be trying to
generate things elsewhere.  I'd like mk-release to continue to work
for older branches, too, so it's going to be some sort of hybrid mess
for a few years here.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Statistics Import and Export
Next
From: Tomas Vondra
Date:
Subject: Re: pg_combinebackup --copy-file-range