[ipxe-devel] reproducible builds, what if

Christian Nilsson nikize at gmail.com
Mon May 4 06:03:43 UTC 2020


On Mon, 4 May 2020, 13:32 Michael Brown, <mcb30 at ipxe.org> wrote:

> On 04/05/2020 02:10, Neil Roza wrote:
> >     On Sun, May 03, 2020 at 12:18:26PM +0900, Christian Nilsson wrote:
> >      > What if there is any local non commited changes, or config file
> >     changes, or
> >      > embedded script changes. The checksum over linked solves the
> >     hash, but is
> >      > it actually correct to use git as a source for BUILD_TIMESTAMP
> >     when there
> >      > is local changes?
> >
> >     I see the warning, but I don't see the problem.
> >     In case that doesn't answer the "What if question",
> >     please elaborate what the hidden danger is.
> >
> > No, I get it: a pristine HEAD and a dirty HEAD don't deserve the same
> > source date epoch. There's some ways to disambiguate these with `git
> > stash`, but this is starting to get complicated. It could become an ugly
> > `$(shell ...)` in the Makefile.housekeeping, or I could put it in a
> > helper shell script. What's the right decision for ipxe?
>
> BUILD_TIMESTAMP has a weaker requirement than BUILD_ID: it gets used
> only as a means to automatically select the newest version of iPXE if
> multiple iPXE drivers are loaded concurrently in a UEFI system.  It's
> already rounded down to the nearest minute when used for that purpose.
>
> For BUILD_TIMESTAMP (but not BUILD_ID), I am happy with using the commit
> date as extracted from git.
>

Good, can we just make sure that the purpose and usage is documented in the
makefile as well?

>
> Michael
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo/ipxe-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20200504/6563b75e/attachment.htm>


More information about the ipxe-devel mailing list