MIME-Version: 1.0
References: <DFCDD5H4J7VX.3GJKRBBDCKQ86@jeltef.nl>
 <CAExHW5tuJTmuikfkabWq+mvomucY3iQ_vV-10KAsZWM7Yg6tvg@mail.gmail.com>
 <3913298.1767194804@sss.pgh.pa.us>
 <5611b8aa-8496-4632-92b4-e096654850d1@dunslane.net>
 <DGTVWJWZB0C9.CKSLBGGSXN4F@jeltef.nl>
 <de91907e-fa32-4bec-968b-1099479dae16@eisentraut.org>
 <DH1IHNI06K3E.35YUXK4EVN8D6@jeltef.nl>
 <4645a523-8774-45d8-894e-9c83d5954155@eisentraut.org>
 <1194980.1774623323@sss.pgh.pa.us>
In-Reply-To: <1194980.1774623323@sss.pgh.pa.us>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Fri, 27 Mar 2026 16:28:03 +0100
Message-ID: 
 <CAGECzQTHHiLmS62LADQk+CMxoC5u0RtYzpjBbB7hKaq70YQn-Q@mail.gmail.com>
Subject: Re: Add "format" target to make and ninja to run pgindent and
 pgperltidy
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>,
 Andrew Dunstan <andrew@dunslane.net>,
	Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Daniel Gustafsson <daniel@yesql.se>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAGECzQTHHiLmS62LADQk%2BCMxoC5u0RtYzpjBbB7hKaq70YQn-Q%40mail.gmail.com>
Precedence: bulk

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.