Re: [PROPOSAL] time zones and reproducible builds (was: How to make groff use local timezone?)

[Wim Stockman]

Hello fellow groffers,

As a consumer , archiver of pdf documents, image files and others. I'm
confronted with all that goes wrong when trying to keep systemdates of file
synced and keep the same as the original creation date. I've had so many
issues with systemdates that or wrongly set , or a webdav service that
doesn't keep the original timestamps , bios clock on wrong settings etc...
So I only rely on the creation dates set in the files as this is by far the
most reliable method. So this is my pledge to keep this data in the file.
Even if the time zone is wrong, the date is still correct.
Keep up the good work.

Kind regards
Wim Stockman

Op di 22 dec. 2020 04:41 schreef G. Branden Robinson <
g.branden.robinson@gmail.com>:

> At 2020-12-21T23:33:18+0000, Deri wrote:
> > On Sunday, 20 December 2020 06:10:25 GMT G. Branden Robinson wrote:
> > > 2.  Switch output of date comments embedded by output drivers off by
> > >     default, and add a common option to reënable them.  Document this
> in
> > >     NEWS.
> > > 3a. Add a device-independent output command, something like "x
> > >     timestamp", which records the time gathered by input.cpp.
> > > 3b. Modify the HTML, PDF, and PostScript output drivers to initialize
> > >     their idea of the current time from this new command instead of
> > >     calling libgroff's `current_time()` themselves.
> > > 3c. At that point the only call site of `current_time()` will be
> > >     input.cpp.  Maybe the function should be moved out of the library.
> > >
> >
> > I may be misunderstanding something here, apologies if I am.
>
> No, I appreciate you speaking up--I welcome critical evaluation of my
> suggestions, especially in cases like this where I haven't carved out
> enough time to experiment and research an issue as much as is my usual
> preference.
>
> > Both grops and gropdf use the time given in SOURCE_DATE_EPOCH if it is
> > present to embed in the meta-data. This was to assist in making
> > reproducible builds. The coding of "current_time()" in curtime.cpp is
> > also aware of this setting.
>
> Yes, and in fact I see that current_time() is in its entirely Colin's
> work[1].
>
> > So I thought the only problem was the sorting objects in the output
> > file, for which we have a patch.
>
> Yes, and it's pushed now, too.  I expect to do some build-diffing today.
>
> ...and in the time since I started composing this mail, I've done it.
>
> > Am I missing something, or are 2 and 3 required to create reproducible
> > builds?
>
> It may have been I who missed something.  I had vivid unpleasant
> memories of those %%CreationDates in the diffs but back when I was
> diffing builds I never set SOURCE_DATE_EPOCH because I thought I had no
> reason to.
>
> The short version is that you're right and neither steps 2 nor 3 are
> necessary.  We do still have some work to do in other areas--mainly
> pdfroff it looks like.  I'll follow up to the bug about this.
>
> > In cases where reproducible builds are not necessary having the output
> > drivers embed the time when they actually ran can be useful. Consider
> > the case where multiple -Z produced groff files, produced at different
> > times, are combined into one gropdf run. The only sensible time to
> > include in the meta-data is the time the pdf was created, why lose
> > potentially useful information?
>
> There is an argument to be made that's a channel for information
> leakage, but even if that is the case it may be niche enough to support
> an output driver option for _suppressing_ its output rather than
> enabling, and let the paranoids supply -P options to the formatter to
> close that channel.
>
> Since a discussion has started on the semantics of the embedded date in
> PDFs I will watch for an outcome of this discussion.
>
> Another possible factor is that the idea of implementing a new "x"
> command for the device-independent format language sounded exciting to
> me.  As engineers we have to be mindful of the urge for featuritis.  :D
> I'm certainly not immune.
>
> Regards,
> Branden
>
> [1] https://lists.gnu.org/archive/html/groff-commit/2016-07/msg00000.html
>