Do the file timestamps in ISOs matter ?

[Thomas Schmitt]

Hi,

Chris Lamb wrote:
> I just don't see this usecase of being "partly" reproducible being remotely
> useful to anyone, ever. I'm probably misunderstanding something, however.

All three possible behaviors lead to reproducibility if the input trees
of the ISO production runs are sufficiently similar.

The undecided question is, as the subject says, how much similarity is
most likely needed. The more - the harder to reproduce.

- If ctime and/or atime of files in the input tree matter, then they
  should not be overridden by SOURCE_DATE_EPOCH.
  I.e.:  --set_all_file_dates  "default"

  Reproducibility would break quite easily unless the input filesystem
  is read-only.

- If mtime stamps of input tree matter, then they should not be overridden
  by SOURCE_DATE_EPOCH.
  I.e.:  --set_all_file_dates  "set_to_mtime"

  Reproducibility would survive input tree operations like cp -a.

- File timestamps in the ISO do not matter and rather are just a potential
  obstacle for reproducibility, then SOURCE_DATE_EPOCH should override them.
  I.e.:  --set_all_file_dates  ="$SOURCE_DATE_EPOCH"

  Reproducibility would survive any operation that preserves name tree,
  ownership, permissions, and file content.
  (Ownership and permissions could be flattened by xorrisofs option -r.)

The latter two are what i would consider reasonable for general purposes.
I myself with my purpose of repacking existing ISOs and checking for
regressions could even live with the first one.


> Therefore folding it all into inheriting {a,c}time from mtime iff S_D_E
> is the logical conclusion,

If "iff" means "if and only if", then i have to contradict:
SOURCE_DATE_EPOCH is not the only way to achieve mtime to ctime,atime copying.
That's a consequence of how i implement it.
So it's only "if", not "iff".


> there is need to for people who "just"
> want a reproducible ISO to tediously scour the documentation to discover
> they need to set --set_all_file_dates.

No. SOURCE_DATE_EPOCH makes the ISO reproducible if it does not get
overriden by non-constant parameters of the program options which one
would have to look for (after man page section ENVIRONMENT listed them
as explanation of SOURCE_DATE_EPOCH).

Another precondition is that the input trees are sufficiently similar,
of course.

The proposal to set all file timestamps to SOURCE_DATE_EPOCH would actually
"just" ease the production of reproducible ISOs.


> > grub-mkrescue
> They won't be run with SOURCE_DATE_EPOCH exported.

When xorriso-1.4.6 is out i plan to ask grub-devel to introduce an option
in grub-mkrescue which overrides the "now" time when the argument for
xorrisofs option --modification-date= is determined.
Maybe i can talk them into deducing the --modification-date= string from
SOURCE_DATE_EPOCH.
(If "set_to_mtime" wins the election, then the actual time value of
 SOURCE_DATE_EPOCH will get overridden by --modification-date= completely.)


Have a nice day :)

Thomas