From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: bug#35283: ISO images are not reproducible Date: Fri, 19 Apr 2019 14:46:48 +0200 Message-ID: <11201672983044432889@scdbackup.webframe.org> References: <875zrafck7.fsf_-_@gnu.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:44518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHSt6-0000t8-LM for bug-guix@gnu.org; Fri, 19 Apr 2019 08:45:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hHSt5-0005PV-DQ for bug-guix@gnu.org; Fri, 19 Apr 2019 08:45:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:58251) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hHSt5-0005PF-AX for bug-guix@gnu.org; Fri, 19 Apr 2019 08:45:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hHSt5-0000Ok-6e for bug-guix@gnu.org; Fri, 19 Apr 2019 08:45:03 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <875zrafck7.fsf_-_@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: bug-xorriso@gnu.org Cc: 35283@debbugs.gnu.org Hi, > Files added by =E2=80=98grub-mkrescue=E2=80=99 are =E2=80=9Cout of our c= ontrol=E2=80=9D so we would need > to patch =E2=80=98grub-mkrescue=E2=80=99 to honor SOURCE_DATE_EPOCH, for= example. Google shows that patches have been proposed. But they seem not to have made it into the source. Vladimir Serbinko's answer here https://lists.gnu.org/archive/html/grub-devel/2015-12/msg00046.html might be the reason. I understand that he demands uniqueness of UUIDs. But that's not really a problem with reproducible ISOs. If pseudo-random UUIDs depend deterministically on SOURCE_DATE_EPOCH, then collisions are only to expect between ISOs made with the same seconds value. This can also happen if non-reproducible ISOs are made while their systems' clocks show the same time by mere incident. So one should use SOURCE_DATE_EPOCH values with best possible entropy. Not one humanly invented lucky number for all ISOs of a distro. If ever two identical ISOs are offered to GRUB at boot time, it needs some imagination to construct a problem if GRUB operates on the one which was not used by the EFI firmware to start GRUB. So when a reproducible ISO is made for the first time, its SOURCE_DATE_EPO= CH should be taken from "date +%s" and recorded for further runs. The ISO will bear it as "Creation Time", like "2019021612165300". The last two digits "00" are centiseconds and should be ignored even if not "00". If decoding that time back to seconds-since-1970 is cumbersome, one may store the seconds value in a data file in the input tree of the ISO before packing up by a xorriso run with SOURCE_DATE_EPOCH having that value. > after rereading the Xorriso manual, it seemed to me that if we > set SOURCE_DATE_EPOCH and pass: > -volume_date all_file_dates set_to_mtime > then all the files would have the mtime specified by SOURCE_DATE_EPOCH, > which would solve the problem. This is the support for ignoring atime and ctime changes of input files but respecting their mtime changes. If you want a fixed time for all three timestamps in all files, do: -volume_date all_file_dates =3D"$SOURCE_DATE_EPOCH" The "=3D" announces seconds-since-1970 as time format. See -alter_date. Note that in this proposal $SOURCE_DATE_EPOCH is evaluated by the shell, not by xorriso. Depending on the way how xorriso is started, you need to insert the actual number. Have a nice day :) Thomas