[Pkg-libburnia-devel] Reproducible patches for libisoburn and libisofs

[Thomas Schmitt]

Hi,

i have to correct myself about the boot catalog file node.
It gets created at a point of time after which normal image manipulation
still can be applied. So it would be no problem together with option
--set_all_file_dates.

In general adding this synthetic file to a reproducible ISO invites trouble.
It gets its timestamp when the override by --modification-date= might not
yet be in effect.
But it is quite common.
One point for your set-them-all approach.

Similar with the GPT UUIDs. I cannot keep people from demanding GPT.
Especially with grub-mkrescue, where it is produced in UEFI compliant way.
But the entropy of --modification-date= is not enough to produce byte strings
which deserve the name UUID. Even if they shall not be unique but common
to a small family of identical ISOs.


I need to think ...

------------------------------------------------------------------------

> (Seen/used our diffoscope tool, btw?)

Before i find a good tool and learn how to operate it, i normally write
one myself which merely fits my needs.
  Usage: hxd [-line_len N] [-diff file1 file2] [-cdtext [-c_code]]

Normally it serves me as alternative to od.

  00008020 :    20  20  20  20  20  20  20  20  44  65  62  69  61  6e  20  38
                                                 D   e   b   i   a   n       8
     32800 :    32  32  32  32  32  32  32  32  68 101  98 105  97 110  32  56

  00008030 :    2e  34  2e  30  20  61  6d  64  36  34  20  31  20  20  20  20
                 .   4   .   0       a   m   d   6   4       1                
     32816 :    46  52  46  48  32  97 109 100  54  52  32  49  32  32  32  32

With:

  hxd -diff /dvdbuffer/test.iso /dvdbuffer/test1.iso

it yields text blocks like this

       528 :    62 168  47 127   0   0   0   0   1   0   0   0   0   0   0   0
                 >       /                                                    
  00000210 :    3e  a8  2f  7f  00  00  00  00  01  00  00  00  00  00  00  00
               ### ### ### ###                                                 
  00000210 :    9e  8f  b0  20  00  00  00  00  01  00  00  00  00  00  00  00
                                                                            
       528 :   158 143 176  32   0   0   0   0   1   0   0   0   0   0   0   0


       560 :   202 175   7   0   0   0   0   0  29  71 249 239  30 111  17  73
                                                     G               o       I
  00000230 :    ca  af  07  00  00  00  00  00  1d  47  f9  ef  1e  6f  11  49
                                               ### ### ### ### ### ### ### ### 
  00000230 :    ca  af  07  00  00  00  00  00  e6  d9  7c  4f  12  8e  dd  48
                                                         |   O               H
       560 :   202 175   7   0   0   0   0   0 230 217 124  79  18 142 221  72


Then i need to find out what role those bytes play in the ISO.
(Here: GPT header block.)


> > I have to put the plight on you to trigger this by an extra option.

> I'm really sorry but I believe that in your polite and kind manner I
> have lost what you are saying. :(

Translation:
You will have to use --set_all_file_dates unless you or the code surprise
me with new aspects.


> > timestamps of the Boot Catalog file. Caused by

> This amuses me quite a bit as I actually had a patch that changed this
> (Note that I believe this appears in the diffoscope output above.)
>  ----------   0    0    0            2048 Aug  5 2016 [    102 00]  boot.cat 

The time granularity of isoinfo is too coarse to show the difference.
You'd need to wait a day between ISOs.

> │ -----------   0    0    0          38912 Aug  5 2016 [ 209401 00]  boot.bin 
> │ +----------   0    0    0          38912 Aug  5 2016 [ 225946 00]  boot.bin 
> ...
> ├── boot/boot.cat
> | -00000020: 8800 0000 0000 0400 f931 0300 0000 0000  .........1......
> │ +00000020: 8800 0000 0000 0400 9a72 0300 0000 0000  .........r......

That's rather the different extent address of /boot/boot.bin being published
by boot.cat :  209401 = 0x000331f9 , 225946 = 0x0003729a
(Read backwards as       f931 0300 ,           9a72 0300)

> ├── boot/boot.bin
> │ @@ -1,8 +1,8 @@
> │ -00000000: faea 6c7c 0000 9090 1000 0000 f931 0300  ..l|.........1..
> │ +00000000: faea 6c7c 0000 9090 1000 0000 9a72 0300  ..l|.........r..

By option -boot-info-table the file boot.bin gets patched-in its own block
address.
That's because BIOS only loads 2048 bytes which then get executed and must
load the rest of the program. Among the code parts which wait for being
loaded is the ISO 9660 driver.

Well, if the extent addresses are reproducible, then these fields are
reproducible, too. xorriso-1.4.2 and later should have it fixed.


Have a nice day :)

Thomas