[ipxe-devel] reproducible builds

[Michael Brown]

On 01/05/2020 23:36, Neil Roza wrote:
> Please find the attached diff representing a patch I would like to 
> submit for your consideration. This is a small change to the 
> `src/Makefile.housekeeping` that makes the generation of most artifacts 
> (notably not `*.usb` images) deterministic.
> 
> The scariest change here is the removal of the `BUILD_ID_CMD` in favor 
> of an inlined shell snippet where the `_build_id` symbol is defined. In 
> keeping with the comments that specify a unique `_build_id` for each 
> `$(BIN)/%.tmp`, I use the first 8 characters of the md5sum of the 
> target, in the expected base-prefixed hexadecimal representation. 
> Calculating the likelihood of collisions I leave as an exercise to the 
> reviewer. :D

The existing comment in the Makefile is not especially clear, sorry. 
The build ID is supposed to be collision-free across all ROMs that might 
ever end up installed in the same system.  It doesn't just disambiguate 
targets within a single build; it also disambiguates different builds.

It gets used by the ROM prefix to determine when another ROM in the 
system contains identical code.  This happens when, for example, a 
multi-port NIC exposes the same iPXE ROM image for several different PCI 
functions, or when two identical NICs are installed in the same system. 
We need to know this in order to save space within the legacy BIOS 
option ROM area, which is extremely limited in size.

Hashing the build target name is not sufficient, because that would 
result in a collision between the same ROM built at different times from 
different source trees.

> The `BUILD_TIMESTAMP` assignment has been changed to allow environment 
> variable overriding, but it defaults to `SOURCE_DATE_EPOCH`. The source 
> date epoch can also be overridden; it defaults to the Unix timestamp of 
> the current git HEAD commit.

This seems like a reasonable approach, but would need to fail gracefully 
when built from something that isn't a git checkout.  See the way that 
VERSIONS is handled for an example.

Thanks,

Michael