Reproducible builds: genbki.pl vs schemapg.h

Christoph Berg <christoph.berg@credativ.de> writes:

Debian's reproducible builds project has revealed that the full build
path gets embedded into server/catalog/schemapg.h:

genbki.pl is hardly our only script that prints its $0 ...

regards, tom lane

Re: Tom Lane 2017-12-15 <9616.1513351766@sss.pgh.pa.us>

Christoph Berg <christoph.berg@credativ.de> writes:

Debian's reproducible builds project has revealed that the full build
path gets embedded into server/catalog/schemapg.h:

genbki.pl is hardly our only script that prints its $0 ...

As per
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/postgresql-10.html,
that's the only place that makes it into the resulting binary.
I wouldn't be sending a patch if it didn't fix the issue.

Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB M�nchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 M�nchengladbach
Gesch�ftsf�hrung: Dr. Michael Meskes, J�rg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970 87C6 4C5A 6BAB 12D2 A7AE

On Sat, Dec 16, 2017 at 3:13 AM, Christoph Berg
<christoph.berg@credativ.de> wrote:

Re: Tom Lane 2017-12-15 <9616.1513351766@sss.pgh.pa.us>

Christoph Berg <christoph.berg@credativ.de> writes:

Debian's reproducible builds project has revealed that the full build
path gets embedded into server/catalog/schemapg.h:

genbki.pl is hardly our only script that prints its $0 ...

As per
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/postgresql-10.html,
that's the only place that makes it into the resulting binary.
I wouldn't be sending a patch if it didn't fix the issue.

Why not fixing that? Reproducible builds are a trend of these days,
and what's proposed here is really simple to make PG more compliant
with this purpose in mind.
--
Michael

On 2017-12-16 07:52:41 +0900, Michael Paquier wrote:

On Sat, Dec 16, 2017 at 3:13 AM, Christoph Berg
<christoph.berg@credativ.de> wrote:

Re: Tom Lane 2017-12-15 <9616.1513351766@sss.pgh.pa.us>

Christoph Berg <christoph.berg@credativ.de> writes:

Debian's reproducible builds project has revealed that the full build
path gets embedded into server/catalog/schemapg.h:

genbki.pl is hardly our only script that prints its $0 ...

As per
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/postgresql-10.html,
that's the only place that makes it into the resulting binary.
I wouldn't be sending a patch if it didn't fix the issue.

Why not fixing that? Reproducible builds are a trend of these days,
and what's proposed here is really simple to make PG more compliant
with this purpose in mind.

It's not like $0 instead of a hardcoded name in the header actually buys
us anything afaict.

Greetings,

Andres Freund

On Fri, Dec 15, 2017 at 3:21 PM, Andres Freund <andres@anarazel.de> wrote:

Why not fixing that? Reproducible builds are a trend of these days,
and what's proposed here is really simple to make PG more compliant
with this purpose in mind.

It's not like $0 instead of a hardcoded name in the header actually buys
us anything afaict.

+1.

I think that reproducible builds are a worthwhile goal, and I welcome
Christoph's continued work on them.

--
Peter Geoghegan

Andres Freund <andres@anarazel.de> writes:

On 2017-12-16 07:52:41 +0900, Michael Paquier wrote:

On Sat, Dec 16, 2017 at 3:13 AM, Christoph Berg
<christoph.berg@credativ.de> wrote:

Re: Tom Lane 2017-12-15 <9616.1513351766@sss.pgh.pa.us>

genbki.pl is hardly our only script that prints its $0 ...

As per
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/postgresql-10.html,
that's the only place that makes it into the resulting binary.

I'm fairly confused by this claim. Since the string in question is in a
comment, it really shouldn't affect built binaries at all. I can believe
that it would affect the non-binary contents of the finished package,
because we include schemapg.h as one of the installed headers. However,
we also include fmgroids.h, which also has an expanded version of $0
in it. So if schemapg.h is affected by build path, why isn't fmgroids.h?

In my build, neither one of these files contains any path information;
I speculate that you need to use a VPATH build to have an issue, or
maybe Debian's build environment does something even weirder. But
I feel confident in saying that if indeed fmgroids.h is invariant for
you today, that's a phase-of-the-moon behavior that will break someday
if we don't make a similar change in Gen_fmgrtab.pl. Or else we should
propagate what's preventing it back to genbki.pl.

plperl's text2macro.pl is also emitting $0, and there may be other places
I missed (I grepped for 'DO NOT EDIT', not for $0 per se). We seem not
to install the output file of that one, perlchunks.h, but that's a
decision that somebody might change too.

It's not like $0 instead of a hardcoded name in the header actually buys
us anything afaict.

Agreed so far as the script name goes. However, two out of three of these
scripts also print their input file names, and I'm suspicious that that
output is also gonna change in a VPATH build. I'm a little less inclined
to buy the claim that we're not losing anything if we suppress that :-(

regards, tom lane

Re: Tom Lane 2017-12-16 <5525.1513381145@sss.pgh.pa.us>

As per
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/postgresql-10.html,
that's the only place that makes it into the resulting binary.

I'm fairly confused by this claim. Since the string in question is in a
comment, it really shouldn't affect built binaries at all. I can believe
that it would affect the non-binary contents of the finished package,

"Binary" in that context was the .deb package file (in contrast to the
.dsc source package).

In my build, neither one of these files contains any path information;
I speculate that you need to use a VPATH build to have an issue, or
maybe Debian's build environment does something even weirder.

This is a VPATH build, yes.

It's not like $0 instead of a hardcoded name in the header actually buys
us anything afaict.

Agreed so far as the script name goes. However, two out of three of these
scripts also print their input file names, and I'm suspicious that that
output is also gonna change in a VPATH build. I'm a little less inclined
to buy the claim that we're not losing anything if we suppress that :-(

Well, patching this instance of $0 would fix a binary-package
variation in practise. Of course there might be more issues waiting to
come into effect, but I don't see why that would be an argument
against fixing the current issue.

Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB M�nchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 M�nchengladbach
Gesch�ftsf�hrung: Dr. Michael Meskes, J�rg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970 87C6 4C5A 6BAB 12D2 A7AE

Christoph Berg <christoph.berg@credativ.de> writes:

Agreed so far as the script name goes. However, two out of three of these
scripts also print their input file names, and I'm suspicious that that
output is also gonna change in a VPATH build. I'm a little less inclined
to buy the claim that we're not losing anything if we suppress that :-(

Well, patching this instance of $0 would fix a binary-package
variation in practise. Of course there might be more issues waiting to
come into effect, but I don't see why that would be an argument
against fixing the current issue.

I think we're talking at cross-purposes. I'm not saying we should not fix
this problem. I'm saying that the proposed fix appears incomplete, which
means that (a) even if it solves your problem, it probably does not solve
related problems for other people; (b) since it's not clear why this
patch is apparently sufficient for you, I'd like to understand that in
some detail before deeming the problem solved; and (c) leaving instances
of the problematic code in our tree is just about guaranteed to mean
you'll have the same problem in future, when somebody either copies that
coding pattern into some new script or tweaks the way those existing
scripts are being used.

regards, tom lane

Re: Tom Lane 2017-12-16 <417.1513438031@sss.pgh.pa.us>

I think we're talking at cross-purposes. I'm not saying we should not fix
this problem. I'm saying that the proposed fix appears incomplete, which
means that (a) even if it solves your problem, it probably does not solve
related problems for other people; (b) since it's not clear why this
patch is apparently sufficient for you, I'd like to understand that in
some detail before deeming the problem solved; and (c) leaving instances
of the problematic code in our tree is just about guaranteed to mean
you'll have the same problem in future, when somebody either copies that
coding pattern into some new script or tweaks the way those existing
scripts are being used.

Grepping through the source, there are three places where $0 printed
to files in regular operation (as opposed to being used in --help):

* src/backend/catalog/genbki.pl
* It has been GENERATED by $0

* src/backend/utils/Gen_fmgrtab.pl
* It has been GENERATED by $0

* src/backend/utils/mb/Unicode/convutils.pm, a perl module used by
src/backend/utils/mb/Unicode/*_to_*.pl
my $this_script = $0;
print $out "/* This file is generated by $this_script */\n\n";

The latter is not relevant because the generated .map files just
included in other .c files, but not shipped in source. (And a changed
comment does not modify the build result.)

The first case is fixed in my original patch, the updated patch
catches the second as well.

I believe the reason why we've only been seeing half of the problem
yet is that the generated files are shipped with the tarballs, so it
might be a timestamping issue determining if the scripts are
re-executed.

Filed as https://commitfest.postgresql.org/16/1417/

Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB M�nchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 M�nchengladbach
Gesch�ftsf�hrung: Dr. Michael Meskes, J�rg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970 87C6 4C5A 6BAB 12D2 A7AE

Christoph Berg <christoph.berg@credativ.de> writes:

Re: Tom Lane 2017-12-16 <417.1513438031@sss.pgh.pa.us>

I think we're talking at cross-purposes. I'm not saying we should not fix
this problem. I'm saying that the proposed fix appears incomplete ...

Grepping through the source, there are three places where $0 printed
to files in regular operation (as opposed to being used in --help):

I poked around and found a few more.

I believe the reason why we've only been seeing half of the problem
yet is that the generated files are shipped with the tarballs, so it
might be a timestamping issue determining if the scripts are
re-executed.

Right; some parts of this problem would only materialize for you if you
needed to rebuild the generated files that are included in the tarball,
which should basically not be happening in normal packager builds.
Rather the risk is at our end: if we ever switched the tarball creation
process to be a VPATH build, then there'd be path dependencies in the
created tarballs. That would be bad.

More generally, my concern here is not just that we fix this problem
but that it stays fixed. If some individual scripts print $0 into
their output and it happens to not affect any built distribution files
today, it's still bad, because tomorrow somebody might copy that coding
pattern into someplace else where it matters more. I think we need a
project policy that thou shalt not print $0 into generated files, period.

Also, experimenting with a VPATH build, I verified that such "helpful"
practices as printing $infile or @ARGV into the output file will also
create path dependencies. So I think we need to lose those too.
It's not like they're adding any info you can't find out from the
Makefiles.

On the other hand, there is something we can do that will improve
matters: rather than just printing the base name of the script,
let's print its full relative path within the PG sources, eg instead
of Gen_fmgrtab.pl let's print src/backend/utils/Gen_fmgrtab.pl.
My thought here is that if you're not already intimately familiar
with a script you might not remember where it lives, the more so
if you're looking at a file that's been put into an installation
tree far away from where it was generated. I see that this policy
was already followed in some places, just not in the ones that were
using the $0 shortcut.

In short, I propose the attached more-extensive patch.

Some of the files generated by these scripts, particularly the map
files generated by the src/backend/utils/mb/Unicode/ scripts, are
not just present in tarballs but are actually in our git repo.
So changing those scripts won't affect anything until/unless someone
updates the repo's generated files, which I've not done here and
don't feel much need to do. I just want to establish a principle
that we don't print path-dependent info into generated files.

regards, tom lane

On 12/20/2017 09:50 PM, Tom Lane wrote:

Christoph Berg <christoph.berg@credativ.de> writes:

Re: Tom Lane 2017-12-16 <417.1513438031@sss.pgh.pa.us>

I think we're talking at cross-purposes. I'm not saying we should not fix
this problem. I'm saying that the proposed fix appears incomplete ...

Grepping through the source, there are three places where $0 printed
to files in regular operation (as opposed to being used in --help):

I poked around and found a few more.

I believe the reason why we've only been seeing half of the problem
yet is that the generated files are shipped with the tarballs, so it
might be a timestamping issue determining if the scripts are
re-executed.

Right; some parts of this problem would only materialize for you if you
needed to rebuild the generated files that are included in the tarball,
which should basically not be happening in normal packager builds.
Rather the risk is at our end: if we ever switched the tarball creation
process to be a VPATH build, then there'd be path dependencies in the
created tarballs. That would be bad.

More generally, my concern here is not just that we fix this problem
but that it stays fixed. If some individual scripts print $0 into
their output and it happens to not affect any built distribution files
today, it's still bad, because tomorrow somebody might copy that coding
pattern into someplace else where it matters more. I think we need a
project policy that thou shalt not print $0 into generated files, period.

Also, experimenting with a VPATH build, I verified that such "helpful"
practices as printing $infile or @ARGV into the output file will also
create path dependencies. So I think we need to lose those too.
It's not like they're adding any info you can't find out from the
Makefiles.

On the other hand, there is something we can do that will improve
matters: rather than just printing the base name of the script,
let's print its full relative path within the PG sources, eg instead
of Gen_fmgrtab.pl let's print src/backend/utils/Gen_fmgrtab.pl.
My thought here is that if you're not already intimately familiar
with a script you might not remember where it lives, the more so
if you're looking at a file that's been put into an installation
tree far away from where it was generated. I see that this policy
was already followed in some places, just not in the ones that were
using the $0 shortcut.

In short, I propose the attached more-extensive patch.

Some of the files generated by these scripts, particularly the map
files generated by the src/backend/utils/mb/Unicode/ scripts, are
not just present in tarballs but are actually in our git repo.
So changing those scripts won't affect anything until/unless someone
updates the repo's generated files, which I've not done here and
don't feel much need to do. I just want to establish a principle
that we don't print path-dependent info into generated files.

Looks reasonable. Regarding the change to TestLib.pm, we should make
sure that the tests have unique names. There is a small amount of
duplication currently:

./src/bin/pg_dump/t/001_basic.pl
./src/bin/pg_rewind/t/001_basic.pl
./src/test/modules/commit_ts/t/001_base.pl
./src/test/modules/test_pg_dump/t/001_base.pl

cheers

andrew

--

Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Thu, Dec 21, 2017 at 10:13 PM, Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:

Looks reasonable. Regarding the change to TestLib.pm, we should make
sure that the tests have unique names. There is a small amount of
duplication currently:

./src/bin/pg_dump/t/001_basic.pl
./src/bin/pg_rewind/t/001_basic.pl
./src/test/modules/commit_ts/t/001_base.pl
./src/test/modules/test_pg_dump/t/001_base.pl

Why does the uniqueness of application_name set in the TAP test suite
matter? Each instance of Postgres is self-contained into its own Unix
domain path and port.
--
Michael

On 12/21/2017 08:27 AM, Michael Paquier wrote:

On Thu, Dec 21, 2017 at 10:13 PM, Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:

Looks reasonable. Regarding the change to TestLib.pm, we should make
sure that the tests have unique names. There is a small amount of
duplication currently:

./src/bin/pg_dump/t/001_basic.pl
./src/bin/pg_rewind/t/001_basic.pl
./src/test/modules/commit_ts/t/001_base.pl
./src/test/modules/test_pg_dump/t/001_base.pl

Why does the uniqueness of application_name set in the TAP test suite
matter? Each instance of Postgres is self-contained into its own Unix
domain path and port.

I've found it annoying in the past. Probably now that the buildfarm
reports each test series separately it matters less. Previously we
reported many of the TAP tests together.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Andrew Dunstan 2017-12-21 <d68d254a-6f97-a8c2-4656-ab8886fe2c38@2ndQuadrant.com>

./src/bin/pg_dump/t/001_basic.pl
./src/bin/pg_rewind/t/001_basic.pl
./src/test/modules/commit_ts/t/001_base.pl
./src/test/modules/test_pg_dump/t/001_base.pl

Why does the uniqueness of application_name set in the TAP test suite
matter? Each instance of Postgres is self-contained into its own Unix
domain path and port.

I've found it annoying in the past. Probably now that the buildfarm
reports each test series separately it matters less. Previously we
reported many of the TAP tests together.

Rename them to the directory name:

./src/bin/pg_dump/t/001_pg_dump.pl
./src/bin/pg_rewind/t/001_pg_rewind.pl
./src/test/modules/commit_ts/t/001_commit_ts.pl
./src/test/modules/test_pg_dump/t/001_test_pg_dump.pl

Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB M�nchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 M�nchengladbach
Gesch�ftsf�hrung: Dr. Michael Meskes, J�rg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970 87C6 4C5A 6BAB 12D2 A7AE

Christoph Berg wrote:

Re: Andrew Dunstan 2017-12-21 <d68d254a-6f97-a8c2-4656-ab8886fe2c38@2ndQuadrant.com>

I've found it annoying in the past. Probably now that the buildfarm
reports each test series separately it matters less. Previously we
reported many of the TAP tests together.

Rename them to the directory name:

./src/bin/pg_rewind/t/001_pg_rewind.pl
./src/test/modules/commit_ts/t/001_commit_ts.pl
./src/test/modules/test_pg_dump/t/001_test_pg_dump.pl

These sound good to me.

./src/bin/pg_dump/t/001_pg_dump.pl

There already is t/002_pg_dump.pl. src/bin/pg_dump/t/001_basic.pl is
all about command lines, perhaps we can find a name that evokes that --
001_dump_cmdline.pl? (prefixed "_dump_" to be in line with
t/010_dump_connstr.pl)

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

Looks reasonable. Regarding the change to TestLib.pm, we should make
sure that the tests have unique names. There is a small amount of
duplication currently:

./src/bin/pg_dump/t/001_basic.pl
./src/bin/pg_rewind/t/001_basic.pl
./src/test/modules/commit_ts/t/001_base.pl
./src/test/modules/test_pg_dump/t/001_base.pl

Perhaps, but that's a separate/pre-existing problem no? The point
of the change in my patch was just to avoid getting different
behavior in a VPATH build.

regards, tom lane

On 12/21/17 08:13, Andrew Dunstan wrote:

Looks reasonable. Regarding the change to TestLib.pm, we should make
sure that the tests have unique names. There is a small amount of
duplication currently:

./src/bin/pg_dump/t/001_basic.pl
./src/bin/pg_rewind/t/001_basic.pl
./src/test/modules/commit_ts/t/001_base.pl
./src/test/modules/test_pg_dump/t/001_base.pl

But that's one of the reasons one has directories, so you don't need to
have globally unique names. I don't actually see why the change in
TestLib.pm is necessary or how it relates to this thread.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 12/20/17 21:50, Tom Lane wrote:

-my $this_script = $0;
+my $this_script = 'src/backend/utils/mb/Unicode/UCS_to_BIG5.pl';

This kind of things looks awful. Why is this better?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Sun, Dec 24, 2017 at 12:26:53PM -0500, Peter Eisentraut wrote:

On 12/20/17 21:50, Tom Lane wrote:

-my $this_script = $0;
+my $this_script = 'src/backend/utils/mb/Unicode/UCS_to_BIG5.pl';

This kind of things looks awful. Why is this better?

What's wrong with using the path? As you point out elsewhere on this
thread, it's a way to identify the program uniquely and reproducibly.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate