Re: [PATCH v1 1/2] No insert of the build timestamp into the x86 xen efi binary

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Oct 30, 2020 at 01:08:44PM +0100, Jan Beulich wrote:
> On 30.10.2020 13:03, Frédéric Pierret (fepitre) wrote:
> 
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -170,6 +170,7 @@ EFI_LDFLAGS += --major-image-version=$(XEN_VERSION)
> >  EFI_LDFLAGS += --minor-image-version=$(XEN_SUBVERSION)
> >  EFI_LDFLAGS += --major-os-version=2 --minor-os-version=0
> >  EFI_LDFLAGS += --major-subsystem-version=2 --minor-subsystem-version=0
> > +EFI_LDFLAGS += --no-insert-timestamp
> 
> Generally I prefer binaries to carry timestamps, when they are
> intended to do so (i.e. when they have a respective field). So
> I think if no timestamp is wanted, it should be as an option
> (not sure about the default).

What about setting it to the SOURCE_DATE_EPOCH[1] variable value, if
present? Of course if there is an option to set explicit timestamp
value.

[1] https://reproducible-builds.org/docs/source-date-epoch/

> This said, I didn't think time stamps got meaningfully in the
> way of reproducible builds - ignoring the minor differences
> cause by them, especially when they sit at well known offsets
> in the binaries, shouldn't be a big deal.

It is a big deal. There is a huge difference between running sha256sum
(or your other favorite hash) on two build artifacts, and using a
specialized tool/script to compare each file separately. Note the
xen.efi may be buried very deep in the thing you compare, for example
inside deb/rpm and then ISO image (installation image), at which point
it's far from "they sit at well known offsets".

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature