libutil: Add a routine to fetch SOURCE_DATE_EPOCH

[markj]

Summary

This will be used in at least makefs and mkimg to ensure that outputs
are reproducible.

[markj]

This is missing a man page, I'll write one once there's some consensus on the interface.

[emaste]

Seems reasonable, but also SOURCE_DATE_EPOCH is intended to override the notion of "now" so should the routine return SOURCE_DATE_EPOCH if set or time(3) if not?

lib/libutil/source_date_epoch.c

5

Foundation-sponsored work should have a Foundation copyright and "This software was developed..." boilerplate.

[markj]

Fix the copyright.

[markj]

In D50271#1146754, @emaste wrote:

Seems reasonable, but also SOURCE_DATE_EPOCH is intended to override the notion of "now" so should the routine return SOURCE_DATE_EPOCH if set or time(3) if not?

It could certainly return the current time if the envvar isn't set. I don't think that would help existing consumers (makefs and mkimg), which derive their timestamps from other sources if SOURCE_DATE_EPOCH isn't set. Maybe they are thus abusing SOURCE_DATE_EPOCH slightly, and the right answer is to always pass the desired timestamp via -T?

[emaste]

The SOURCE_DATE_EPOCH spec doesn't explicitly state this, but based on these points I think it is the intent:

• Build processes MUST use this variable for embedded timestamps in place of the "current" date and time.
• Where build processes embed timestamps that are not "current", but are nevertheless still specific to one execution of the build process, they MUST use a timestamp no later than the value of this variable. This is often called "timestamp clamping".

I think for "use this timestamp instead of the real one from the filesystem" we do want an explicit flag rather than using SOURCE_DATE_EPOCH

[markj]

In D50271#1146801, @emaste wrote:

The SOURCE_DATE_EPOCH spec doesn't explicitly state this, but based on these points I think it is the intent:

• Build processes MUST use this variable for embedded timestamps in place of the "current" date and time.
• Where build processes embed timestamps that are not "current", but are nevertheless still specific to one execution of the build process, they MUST use a timestamp no later than the value of this variable. This is often called "timestamp clamping".

I think for "use this timestamp instead of the real one from the filesystem" we do want an explicit flag rather than using SOURCE_DATE_EPOCH

Ok. I'll hold off on these SOURCE_DATE_EPOCH patches for now. I have some patches for release/ which add support for WITH_REPRODUCIBLE_BUILD, and there, I'm explicitly using -T rather than setting SOURCE_DATE_EPOCH.

Supporting clamping in makefs will require a bit more effort. I guess the routine here should take an additional time_t as input and then:

1. parse the SOURCE_DATE_EPOCH envvar and cache the corresponding time_t in a global var, and
2. compare the cached value with the passed timestamp (representing a "build timestamp"), returning whichever is smaller (typically the SOURCE_DATE_EPOCH value, if it is set).

Do you think it's worth implementing this, given that it probably won't be used in the near future?

[emaste]

Supporting clamping in makefs will require a bit more effort.

I'm not sure that's worth the effort. I've been discussing this in the reproducible-builds IRC channel and there seems to be a consensus:

• SOURCE_DATE_EPOCH isn't intended to override filesystem timestamps
• It can be interpreted as "Behave as if the entire build process occurred at the time specified by SOURCE_DATE_EPOCH"

[markj]

In D50271#1146812, @emaste wrote:

Supporting clamping in makefs will require a bit more effort.

I'm not sure that's worth the effort. I've been discussing this in the reproducible-builds IRC channel and there seems to be a consensus:

• SOURCE_DATE_EPOCH isn't intended to override filesystem timestamps
• It can be interpreted as "Behave as if the entire build process occurred at the time specified by SOURCE_DATE_EPOCH"

Those two points seem a bit incongruent... if the entire build process occurred at the time specified by SOURCE_DATE_EPOCH, then the resulting filesystem timestamps would be equal to SOURCE_DATE_EPOCH. Maybe my mental model of "build process" is wrong.

In any case, I'll leave this alone for now, as it's not required for my immediate goals.

[emaste]

Maybe "entire" build process isn't the way to express it. "Build process step" perhaps -- e.g., as if makefs was run at some given SOURCE_DATE_EPOCH.

Maybe "Behave as if the step in the build process was started at the time given by SOURCE_DATE_EPOCH and completed instantaneously."

[markj]

In D50271#1146815, @emaste wrote:

Maybe "entire" build process isn't the way to express it. "Build process step" perhaps -- e.g., as if makefs was run at some given SOURCE_DATE_EPOCH.

Maybe "Behave as if the step in the build process was started at the time given by SOURCE_DATE_EPOCH and completed instantaneously."

Ok. In that case, makefs isn't really a good match for SOURCE_DATE_EPOCH. What we'd really want is for installworld etc. to use SOURCE_DATE_EPOCH when setting timestamps on installed files.