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

[Thomas Schmitt]

Hi,

it turned out that libisofs buffers the first 32 kB of the ISO for
random access manipulations before it puts them out.

Normally one would find quite some entropy in there, but in the most dull
reproducible case there will only be this individual info:
- ISO image size, range roughly 10,000 to 2,000,000 blocks,
  often aligned to full MiB (= full 512 interval of the range).
- EFI System partition size, range roughly 100 to exactly 16383 blocks,
  often aligned to full MiB (= full 2048 interval of range)
- EFI System Partition location, granularity 2 kB,
  often very low number (normally depends on size of directory tree
  and other meta stuff), range roughly 20 to 1,000.

If we are unlucky, this together is worth less than 24 bits, with the
high risk to have systematic similarities within the ISOs of a distro. 

So still: The entropy seen, before the GPT GUID has to be determined,
is not enough to be base of a default GUID.

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

A new source of irreproducibility appeared: Future xorriso versions.

Andrei Bozenkov on grub-devel corrected my understanding of the relation
of UEFI's definition of GPT GUID and the definition in RFC 4122.
This yields a change in the interpretation of xorriso options

  --gpt_disk_guid modification-date

  --gpt_disk_guid 2303cd2a-73c7-424a-a298-25632da7f446

The next upload of xorriso will not produce the same binary GUIDs
from these options as does the current one.


I will of course try to keep such changes as rare as possible. But it
cannot be totally guaranteed that the same input data and options will
yield the same ISO with future versions of xorriso.
In case of a bug, i'd have few justification to preserve its consequences.

The most obvious reason is the Preparer Id which xorriso writes into
the ISO by default. Current debian-cd ISOs have:

  XORRISO-1.3.6 2014.04.08.180000, LIBISOBURN-1.3.6, LIBISOFS-1.3.6, LIBBURN-1.3.6

whereas currently uploaded GNU xorriso writes by default:

  XORRISO-1.4.5 2016.08.12.185822, LIBISOBURN-1.4.5, LIBISOFS-1.4.5, LIBBURN-1.4.5

This can be overridden by classical mkisofs option -p.
E.g.:

  -p "Yoyodyne Reproducible ISO Maker and xorriso"

(It hurts my developer's feelings to advise overriding of my hallmark.)


Newest version of reproducible ISO checklist:
==========================================================================

- Use xorriso-1.4.5 snapshot 2016.08.12.185822 or newer.
  (Will after release become: Use xorriso-1.4.6 or newer.)

- Best is to use the same xorriso version for all production runs of a
  particular reproducible ISO. Bug fixes or feature enhancements in
  newer versions might cause differences in the resulting ISO images.

  If you cannot outrule a future xorriso upgrade, then you have to override
  the Preparer Id by a reproducible string of your own:

    -p "My Constant Preparer Id"

  and you later have to test whether the new xorriso version really
  produces the same ISOs as the old version did.

  If the xorriso upgrade came as surprise, then you have to obtain the
  old preparer id by e.g.

    xorriso -indev my.iso -pvd_info | grep 'Preparer Id  :'

  and to enforce it in your xorriso runs by e.g.

    -p "XORRISO-1.4.5 2016.08.12.185822, LIBISOBURN-1.4.5, LIBISOFS-1.4.5, LIBBURN-1.4.5"

- Use option

     --modification-date=YYYYMMDDhhmmsscc

  to control the timestamps of the filesystem superblocks and other global
  components of the ISO filesystem.

- If you let xorriso produce GPT, use option

    --gpt_disk_guid modification-date

  to produce GUIDs of low quality, or obtain once a better GUID string
  (e.g. 2303cd2a-73c7-424a-a298-25632da7f446) and use it with each
  reproducible ISO production run by
    --gpt_disk_guid 2303cd2a-73c7-424a-a298-25632da7f446

- Consider to use option
     --set_all_file_dates YYYYMMDDhhmmsscc
  to override the timestamps of the input files and directories.

- Consider to use option
     -r
  to override POSIX ownership and access permissions.

==========================================================================

This becomes lengthy. Wiki article size.


Have a nice day :)

Thomas