FOP-2854: Allow to override CreationDate

[bmwiedemann]

Allow to override build date with SOURCE_DATE_EPOCH
in order to make builds reproducible.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.

This patch was done while working on reproducible builds for openSUSE.

Note: probably only a partial fix towards reproducible pdf output / https://issues.apache.org/jira/browse/FOP-2854

[infosuitemka]

I am out of the office until 04-01-2021. Please contact InfoSuite support at support@infosuite.com for assistance. Note: This is an automated response to your message  "[apache/xmlgraphics-fop] FOP-2854: Allow to override CreationDate (#65)" sent on 23-12-2020 13:59:37. This is the only notification you will receive while this person is away.

[bmwiedemann]

Hi, I would still like to see this reviewed/tested/merged
Anything I can help?

[Simulant87]

This repository seems to be a mirror of the original SVN repository only. So it is unlikely that PRs are accepted here. You can find more information onhow to contribute on the development page: https://xmlgraphics.apache.org/fop/dev/

[infosuitemka]

I am out of the office until 13-12-2021. Please contact InfoSuite support at ***@***.*** for assistance. Note: This is an automated response to your message  "Re: [apache/xmlgraphics-fop] FOP-2854: Allow to override CreationDate (#65)"( sent on 10-12-2021 20:58:56) . This is the only notification you will receive while this person is away.

[bmwiedemann]

Thanks @Simulant87 - I now filed https://issues.apache.org/jira/browse/FOP-3040

[infosuitemka]

I am out of the office until 13-12-2021. Please contact InfoSuite support at ***@***.*** for assistance. Note: This is an automated response to your message  "Re: [apache/xmlgraphics-fop] FOP-2854: Allow to override CreationDate (#65)"( sent on 11-12-2021 07:37:33) . This is the only notification you will receive while this person is away.

[kpcyrd]

@infosuitemka hi! are you back in the office?

[t-8ch]

I have opened a similar PR at #87, which IMO is a bit cleaner.

[jayaddison]

@simonsteiner1984 is this something you could help with reviewing? (a pull request #87 is open to resolve this)

[jayaddison]

@simonsteiner1984 is this something you could help with reviewing? (a pull request #87 is open to resolve this)

Apologies; I misunderstood this to be an issue thread, with a pull request available to resolve it. Now I understand that both are pull requests, so two options are available. I don't have any personal preference between the two.

[simonsteiner1984]

You can use the fop api to override dates, bug is set to wont fix

[t-8ch]

You can use the fop api to override dates, bug is set to wont fix

Not all parts of fop respect the overridden date.

[simonsteiner1984]

We wouldnt use env variables, for passing params to fop

[simonsteiner1984]

Normally we set xmp data from fo file

[simonsteiner1984]

Maybe can be done via https://xmlgraphics.apache.org/fop/2.10/metadata.html

[t-8ch]

Normally we set xmp data from fo file

The xmp data itself yes, but the xmp data timestamp is always the current date.
(Same for the file ID). See the first two commits of #87 .

[jayaddison]

As @t-8ch notes, although many metadata timestamps can be specified at document build-time, xmp:CreateDate is currently an exception to that.

My interest in this bug stems from investigating reproducibility of PDF documentation for Debian's pam package - the only source of variance in recent builds appears to be the xmp:CreateDate in the included PDF files.

[jayaddison]

@simonsteiner1984 Happy New Year to you. Please could you reconsider this pull request, when you find some time?

For some documents it would enable assurance of integrity following rebuilds using straightforward methods like cmp before.pdf after.pdf, instead of manual or process-intensive techniques such as, for example, line-by-line document comparison, or extraction and inspection of PDF content using other utilities.

Similarly for these documents, the ability to rebuild at a fixed point-in-time could enable more reliable/stable hashes for the purposes of archiving and indexing.

Thank you,
James