Allow to clamp mtime to SOURCE_DATE_EPOCH

[bmwiedemann]

Allow to clamp mtime to 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.

Without this patch, openSUSE's scap-security-guide package had variations in /usr/share/xml/scap/ssg/content/ssg-opensuse-ds-1.2.xml for every build:

  <ds:component id="scap_org.open-scap_comp_ssg-opensuse-oval.xml" timestamp="2
021-02-23T09:58:15">

as it was created by oscap ds sds-compose ...

[openscap-ci]

Can one of the admins verify this patch?

[openscap-ci]

Can one of the admins verify this patch?

[bmwiedemann]

related: ComplianceAsCode/content#6642

and then there is one more issue to solve about nondeterminism from filesystem readdir order.

[evgenyz]

Okay, it seems to be important and not really user-facing trick. Maybe you would also fancy creating a test for it?

[evgenyz]

@openscap-ci ok to test

[evgenyz]

@jan-cerny I recall that I once tried to locate the list of environment variables, honored by the scanner, and failed. Do we have it somewhere? If not – I'll create an issue to make one.

[bmwiedemann]

would also fancy creating a test for it

Since I don't know the codebase, I'm usually not good at that. For the test design, there would be 4 cases:

• SOURCE_DATE_EPOCH not set - same as previous behaviour
• SOURCE_DATE_EPOCH=2123456789 - same as previous behaviour (until 2037)
• SOURCE_DATE_EPOCH=invalid - same as previous behaviour
• SOURCE_DATE_EPOCH=1 - all files' mtimes are clamped to 1970-01-01T00:00:01

[evgenyz]

• SOURCE_DATE_EPOCH=2123456789 - same as previous behaviour (until 2037)
• SOURCE_DATE_EPOCH=invalid - same as previous behaviour

Shouldn't these 2 cases raise a warning (the first one until 2037)?

[bmwiedemann]

Shouldn't these 2 cases raise a warning

I try to keep the code as simple as possible. The assumption is that invalid values never happen and values in the future are valid and do not break anything. The future will be past, soon.

[jan-cerny]

@evgenyz

recall that I once tried to locate the list of environment variables, honored by the scanner, and failed. Do we have it somewhere? If not – I'll create an issue to make one.

I think we don't have it.