On Fri, 27 Mar 2026 at 15:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> We did not start expecting commits to be pgindent-clean until pgindent
> was integrated into our tree
Merging these commits does not mean we force committers to run
perltidy on every commit. That a completely separate discussion that
is not worth having until after we make perltidy less of a pain to
run. Even without forcing committers to run perltidy I think 0007 and
0008 are still beneficial.
> The 0008 patch doesn't fix that, and in fact I think it would be
> dangerous to even provide that script in our tree. It's a supply-
> chain attack waiting to happen.
I strongly disagree. Instead I think, our current pgindent README[1]
is a supply-chain attack waiting to happen. Our pgindent README tells
people to get a tar file from the CPAN website, but WITHOUT the
signature checks that the script in 0008 includes. These added
signature checks prevent it from being a supply chain risk.
> Even if it were guaranteed 100%
> secure, too many developers are subject to (perfectly reasonable)
> corporate security policies that would look with disfavor on
> unauthorized installation of Perl modules.
I'd be curious to know which committer is not allowed to download and
run a specific signature verified perl module, but is allowed to get
the latest postgres source code from main.
[1]:
https://github.com/postgres/postgres/blob/9a9998163bda0d8c17d84ea22ced6a60f8018634/src/tools/pgindent/README#L18-L27
P.S. Reading your response, I cannot help but interpret it as an
attempt to sidestep any future discussion about always running
perltidy, by pre-emptively rejecting any and all improvements that
would make perltidy easier to run.
