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

[G. Branden Robinson]

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

signature.asc
Description: PGP signature