[Reproducible-builds] Reproducible patches for libisoburn and libisofs

[Chris Lamb]

Hi Thomas,

Thanks again for the view and battling the list moderation! :)

>      --set_all_file_dates "$timestring"
>   which sets atime, mtime, and ctime of all files, covers your patches
>      0001-source_date_epoch.patch
>      0002-set-default-timestamp.patch

Assuming it also sets iso_write_opts_set_always_gmt, yes. (I think,
anyway..).

I'm not 100% convinced though. I'm a little loathed to drop the
SOURCE_DATE_EPOCH handling in general - zooming out a bit from these
suggested new switches, it does make it somewhat difficult for the
fly-by developer to build a reproducible ISO - they will need to hunt
down and learn the ramifications (and minutiæ of the ISO format) for
all the various command-line arguments that will make the output
reproducible. This seems a little regrettable and perhaps even
slightly antisocial.

In contrast, if we had a single "please make this ISO build
reproducible with this timestamp" toggle, then that would be extremely
straightforward and extensible to all possible future variations where
needed.

(Whether this is a command-line switch or based on the S-D-E environment
variable I'm not particularly fussed, although I would have a preference
for the latter as it's becoming increasing common as more tools adopt it.)


> - Do you agree that i omit
>      0003-set-scdbackup_tag_time-from-source_date_epoch.patch
>   and rather expect that option  --scdbackup_tag  is not to be used when
>   reproducibly building an ISO ?

As I understand the code in Xorriso_make_iso_write_opts, isoburn_igopt_set_scdbackup_tag appears to be called unconditionally - ie. it will always have time(NULL).

>   (Reason is the meaning of the tag in the context of my backup tool
>    scdbackup. A fake timestamp would be flatly wrong.)

Sure, but you would you really be backing up with SOURCE_DATE_EPOCH defined?

>      http://libburnia-project.org/changeset/5733
>   which i derived from your 0004-normalize-wday-yday.patch

Neat!

> > > Is it really desirable/correct to override the timestamps of files when
> > > they get put into the ISO image ?
[..]
> A convenience option for -as mkisofs emulation could do the trick (and
> make the libisoburn patches obsolete).
[..] 
>   xorriso -as mkisofs mkisofs.options... --set_all_file_dates "$timestring" ...

Looks fine, modulo my general comments about SOURCE_DATE_EPOCH at the top
of this email.

> Probably there will be no new function  iso_current_time()  either.
> But if it emerges, then it cannot call exit()

Apologies, I was using "exit()" as a sloppy shorthand for "not silently
returning on error" rather than the literal method to call. Of course,
if there is a message queue or a context-dependent failure mode, we should
use that.

> Considering the birthday paradox, this should be  good enough for about
> 4000 ISOs per day.

Can't /quite/ tell if you're joking! I mean, is anyone building this many
ISOs? Would it matter if their MBR ID clashed? ;-)

> Now i ponder whether it is worth to make it user-adjustable or whether
> i shall derive a reproducible value from the override value of
> --modification-date=.

Mmm, well this is kinda what I was meaning about having a single switch.

> Have a nice day :)

Oh, you too.. and thank you so much for your attention and patience with
my patches.


Regards,

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