makefs: Honor timestamp passsed through 'SOURCE_DATE_EPOCH'

[markj]

Summary

Allow users to specify default timestamps using the 'SOURCE_DATE_EPOCH'
environment variable. Add FFS tests that check timestamps passed
using 'SOURCE_DATE_EPOCH' and make sure -T takes precedence over
'SOURCE_DATE_EPOCH'.

PR: 285630
Sponsored by: Klara, Inc.
Sponsored by: The FreeBSD Foundation

[markj]

usr.sbin/makefs/makefs.8

264–268

This is from D49531?

Presumably SOURCE_DATE_EPOCH should be documented?

usr.sbin/makefs/makefs.c

141

[bnovkov]

Address @markj 's comments.

[bnovkov]

usr.sbin/makefs/makefs.8

264–268

Whoops, not sure how that first manpage change made it here.

I've added the correct change.

[ziaee]

usr.sbin/makefs/makefs.8

605–621

[ziaee]

Oops, just had an even better idea than the suggestion:
"Specify a file-creation timestamp using the same syntax as
.Fl T .
Overridden by
.Fl T ."

Sorry for the noise.
EDIT: Update for markj's explaination.

[markj]

usr.sbin/makefs/makefs.8

612

620

This is backwards, -T overrides SOURCE_DATE_EPOCH.

[emaste]

There's a spec for SOURCE_DATE_EPOCH: https://reproducible-builds.org/specs/source-date-epoch/

It doesn't make reference to suggested priority when there are multiple sources of timestamps, but does indicate it's intended to provide an alternate notion of "now" or "current time" so logically a command-line flag should override it.

Thinking some more about this, SOURCE_DATE_EPOCH actually should not affect the timestamps of files in the produced image (they should come from -T or the file system). SOURCE_DATE_EPOCH should really affect things that would otherwise be the current time, like iso9660's "Volume Creation Date and Time".

[bnovkov]

In D49602#1133494, @emaste wrote:

There's a spec for SOURCE_DATE_EPOCH: https://reproducible-builds.org/specs/source-date-epoch/

Thank you for linking the spec, I wasn't aware of it.

Thinking some more about this, SOURCE_DATE_EPOCH actually should not affect the timestamps of files in the produced image (they should come from -T or the file system). SOURCE_DATE_EPOCH should really affect things that would otherwise be the current time, like iso9660's "Volume Creation Date and Time".

Looking at some of the existing tooling that supports this (namely dosfstools's mkfs.fat), it seems that SOURCE_DATE_EPOCH also gets used for filesystem timestamps, but I think what you proposed is the way to go.

With that in mind, I think it'd best to rework this diff to parse and save the value of SOURCE_DATE_EPOCH and plug any users of current time in separate reviews. A quick glance reveals mtree.c:1057 as one of the offenders, but I'm sure more will pop up.
I'll also make sure that makefs implements proper timestamp clamping, as defined by the SOURCE_DATE_EPOCH spec.
Does that sound reasonable?

[markj]

In D49602#1134702, @bnovkov wrote:

In D49602#1133494, @emaste wrote:

There's a spec for SOURCE_DATE_EPOCH: https://reproducible-builds.org/specs/source-date-epoch/

Thank you for linking the spec, I wasn't aware of it.

Thinking some more about this, SOURCE_DATE_EPOCH actually should not affect the timestamps of files in the produced image (they should come from -T or the file system). SOURCE_DATE_EPOCH should really affect things that would otherwise be the current time, like iso9660's "Volume Creation Date and Time".

Looking at some of the existing tooling that supports this (namely dosfstools's mkfs.fat), it seems that SOURCE_DATE_EPOCH also gets used for filesystem timestamps, but I think what you proposed is the way to go.

With that in mind, I think it'd best to rework this diff to parse and save the value of SOURCE_DATE_EPOCH and plug any users of current time in separate reviews. A quick glance reveals mtree.c:1057 as one of the offenders, but I'm sure more will pop up.
I'll also make sure that makefs implements proper timestamp clamping, as defined by the SOURCE_DATE_EPOCH spec.
Does that sound reasonable?

It sounds reasonable to me, FWIW. We need something similar in mkimg (see D49716), so maybe SOURCE_DATE_EPOCH could be handled with a helper function in libutil? That is, libutil can provide a function which returns a time_t from SOURCE_DATE_EPOCH if it is set.

[bnovkov]

> It sounds reasonable to me, FWIW. We need something similar in mkimg (see D49716), so maybe SOURCE_DATE_EPOCH could be handled with a helper function in libutil? That is, libutil can provide a function which returns a time_t from SOURCE_DATE_EPOCH if it is set.

Right, I imagine more tools will need it as well, so a libutil helper function sounds like the best way to handle this.

[markj]

• Correct the man page (-T overrides SOURCE_DATE_EPOCH, not the other way around)
• Use libutil's source_date_epoch()