[bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH

[Bruno Haible]

Follow-up Comment #8, bug #59658 (project gettext):

3) What the "reproducible builds" initiative is about: See
https://reproducible-builds.org/docs/definition/ .

What are the sources: tarballs or git repos? I don't really mind if you count
only the git repo as the source. Then the POT file and  the PO files became
built files. And since they contain POT-Creation-Date field, people need to
except this field to be different on each build.

This is OK even for the reproducible-builds.org people, since in
https://reproducible-builds.org/docs/plans/ section "Providing a comparison
protocol" they mention that while identical results are "ideal", "Other
technologies might require removing cryptographic signatures or ignore
specific parts." So, "diff -r" that removes POT-Creation-Date lines is OK for
them.

Ultimately, it comes down to the question "can we trust these generated
files?". The harder problem is with binary object code, because a small change
in the source can lead to a big change in the output. But when comparing POT
files and the difference is only in the POT-Creation-Date line, everyone will
answer the question "can we trust these?" with yes.

4)
> they are symptoms, not the issue.  The impossibility of controlling one of
the implicit inputs (the time) is the issue here.

I disagree here, on two reasons:
* In https://reproducible-builds.org/docs/timestamps/ the
reproducible-builds.org people state that the *preferred* way to handle
timestamps is to omit them from the output. This is what I propose (1) for the
en@quot.po files. The SOURCE_DATE_EPOCH is a second-choice mechanism, which
can be useful when you don't want to go into the details.
* The SOURCE_DATE_EPOCH mechanism is dangerous: It can produce output that is
not meaningful. I do not want an xgettext or msginit program that produces
"POT-Creation-Date: 1970-01-01 00:00+0000" or "Automatically generated,
1971.", because that would lead to confusion and trouble for translators.

Everyone can modify the current time on a per-process basis, using tools such
as dateshift http://www.linuxcertif.com/man/1/dateshift/ or time-warp.so
https://www.thanassis.space/tricks.html . So, while everyone can generate
bogus POT files, it should not be that easy.

I want a feature that is not so easy to fool into producing bogus output, even
if it covers only a special case of what you consider a general issue.

5)
> nobody defines SOURCE_DATE_EPOCH on their environment without a concrete
objective, even less by default.

They are defined (or will get defined over time) on many distros. See here
e.g. for Fedora
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/57 and here
for RedHat https://bugzilla.redhat.com/show_bug.cgi?id=1793722 . I'm sure that
if I searched for the build recipes on openSUSE, I would find similar things.

If these distros produce POT files in their source rpms, I don't want them to
contain "POT-Creation-Date: 1970-01-01 00:00+0000".

6)
> their suggested mechanism for git projects is:
> SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)

OK, good to see that there is even a simpler format string directive for
producing a pretty date.

The difference between what you have in mind and what I prefer is that I
prefer a setting in the Makevars file, that can be set by a package
maintainer, and that a distro cannot abuse.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59658>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/