Re: [Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH

[Thomas Schmitt]

Hi,

Alain Knaff wrote:

> Why can't the pcmemtest project just set the TZ
> environment variable to UTC?

Good question.
At least this proposal was not made by Chris Lamb in
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005197
which he started and where we found that mcopy applies the time zone.
I will now add this proposal to that bug report.

Maybe man mcopy should mention SOURCE_DATE_EPOCH and the need to
also set TZ if the resulting filesystem image shall be globally
reproducible.
(I don't see such text in mtools-4.0.37/mcopy.1 )


-----------------------------------------------------------------------
So only interesting in case that TZ is in some way not the solution:

> Weird, I just had a look at that page, and elsewhere it seems to imply
> that SOURCE_TIME_EPOCH should be formatted in the user's timezone:
>
>    Formatting MUST be deferred until runtime if an end user should
>    observe the value in their own locale or timezone.

Yes. After boldly deriving the need for a globally standardized time zone
from the word "UTF" i realized that the specs of reproducible.org shy
away from time zone problems:

  "At present, we do not have a proposal that includes anything
   resembling a "time zone"."

But if the creation of a FAT (or ISO 9660) filesystem shall be world-wide
reproducible, then there has to be some specification of how to deal with
time zones when converting SOURCE_DATE_EPOCH to
Year/Month/Day/Hour/Minute/Seconds.

The rule which you quoted might give a reason to do so:
* FAT needs formatting of SOURCE_DATE_EPOCH.
* One cannot do this at "runtime" of the FAT filesystem, which in the
  special case of pcmtest is when EFI reads the filesystem to find and
  run the \EFI\BOOT\BOOT*.EFI start program.
=> So one must not let the end user see their own locale or timezone.


> I guess it depends on which part of the document you give
> more weight...

Well, the weight is on the purpose of https://reproducible-builds.org

  "[...] to allow verification that no vulnerabilities or backdoors have
   been introduced during this compilation process. By promising identical
   results are always generated from a given source, this allows multiple
   third parties to come to a consensus on a “correct” result, [...]"

Obviously encoding local time zones during the "compilation process"
is spoiling this purpose.


> > [my implementation ideas]

> This silently assumes that mk_entry is only ever called with current
> time (or time faked with SOURCE_DATE_EPOCH). However, if preserveTime is
> set, it might be called with the timestamp of the source file, and in
> that case, it should be formatted with localtime rather than gmtime.

I had similar problems when implementing SOURCE_DATE_EPOCH in xorriso,
which has to produce Year/Month/Day/Hour/Minute/Seconds/Timezone
in the Volume Descriptors of ISO 9660.
xorriso is intended to be entirely controlled by its commands, which can
make and revoke particular program settings.

My solution was to let SOURCE_DATE_EPOCH set the defaults but to allow
xorriso commands to override these defaults. Those commands should of
course be used with care when reproducible build of an ISO is desired.

Chris Lamb was not fully happy with that solution.
But it works well in practice. Nobody came yet to the idea to set
SOURCE_DATE_EPOCH and then to use xorriso commands to override the default
settings which it caused.

In the same way, mcopy could take its option -m as reason to enable
local time zone although SOURCE_DATE_EPOCH is present.


> IMHO, all this introduces way too much complexity for a use case which
> is rather niche.

I would not call FAT filesystems for booting via EFI a niche case. :))


Have a nice day :)

Thomas