3 ms·
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
by jdblair 8y 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.
- Fronzie 8y agoWhy 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 ?
- pgeorgi 8y agoThat'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.
- Gibbon1 8y agoWhat 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.
- jdblair 8y agoA 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.