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
