Hacker News new | ask | show | jobs
by jdblair 2669 days ago
Every significant project I've worked on embedded the build host and build time in the resulting executable or firmware image. This was along with other static build information, like version number, compiler version and build flags.

Once you make the sensible choice to include build time in the result you've broken reproducibility. Fixing this means tracking down every package that does this and removing the timestamp.

1 comments

Why is including build time sensible?

If one has reproducible builds, wouldn't a commit/tag from the version control system also do the job of traceability and reproducibility ?

What I've moved to is splating that info into the binaries during the release process. Far as I can tell there aren't standard tools to do that though. At least last time I looked.

Would be nice if there was. I think this is the root of issues such as firmware with the same password/cryto keys across a whole product family instead of unique ones.

That's what coreboot moved to (incl. the timestamp of the commit in its timestamp field) for reproducibility.

Thing is just that host + build time is what was traditionally used. There's no single commit you could use in cvs.

A timestamp is sensible if reproducibility isn't your goal, and exact reproducibility of build artifacts was never a goal on any of my projects. It was simply never a priority.