[Reproducible-builds] Reproducible patches for libisoburn and libisofs

[Chris Lamb]

> Is it really desirable/correct to override the timestamps of files when
> they get put into the ISO image ? I.e. isn't reproducible build supposed to
> be identical only if the input is identical ?

Good question. At least for modification times, I think we *could* go
with asking users to run something like:

  $ find sourcedir/ -newermt '$SOURCE_DATE_EPOCH' -print0 |
        xargs -0r touch --no-dereference --date='$SOURCE_DATE_EPOCH'

.. prior to building, but AIUI one cannot reliably set atime and
ctime so I ended up just overridding if-and-only-if SOURCE_DATE_EPOCH
is set.

> If desirable: What about other file attributes which might change without
> file content change ?

Such as? :)  I didn't think that the ISO format really supported "much". I
mean, I doubt it supports extended attributes or selinux blah..

> Currently it seems to me that xorriso lacks only two features:
[..]
> This does not mean that i would not see the convenience of a single
> option which overrides all variable time stamps.

I would agree, but on the other hand I may be missing some other features
outside of my somewhat narrow usecase.

> With which xorriso commands (or xorriso -as mkisofs options) did you test
> whether the proposed changes suffice for reproducible ISOs ?

Nothing too fancy.

  $ xorriso -as mkisofs \
     --modification-date XXX \
     [boot catalog stuff; am using syslinux] \
     -isohybrid-mbr [..] \
     -V blah -A blah
 
> > +time_t Xorriso__current_time()
> > ...
> > +    if ((errno == ERANGE && (epoch == ULLONG_MAX || epoch == 0))
> > +            || (errno != 0 && epoch == 0))
> > +        return now; 
> 
> Since the application wants a constant time, shouldn't we return some
> constant default value in this case ? (Proposal for a value ? 1970 ?)

To be honest I now feel it should probably exit(EXIT_FAILURE), otherwise
we're just confusing users

> -------------------------------------------------------------------------
> > 0004-normalize-wday-yday.patch
> -------------------------------------------------------------------------
> 
> Where did you get negative effects from not setting  erg->wday , erg->yday ?

Only in the "Understanding timestring" log messages. (parse_exec.c &
opts_p_z.c). It's otherwise harmless as previously mentioned,

> The Unix time functions are tricky and the purpose of the timestamp might
> be the job of an id string when converted back to some time format.
> So it seems best to keep all significant struct members as they are now.

Ah, I didn't know. Thanks.

> > 0003-isohybrid-mbr.patch
[..]
> This weakens the weak random number even in the case of non-constant time:

Indeed I mentioned this in my notes, going on to say that its a terrible
PRNG in either case so it can hardly matter. ;)


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby at debian.org / chris-lamb.co.uk
       `-