The idea is that both builds have reproducible timestamps. So there may be different ways to determine the best way to get the stamp. My rationale was that if the builds are from two different commits, the difference should be reflected in the timestamp. But I agree that two different commits may in principle result in the same binary image. But without the last commit you would end up with different binaries anyway, as the timestamp is usually taken from the time of the build. ________________________________ From: Martin Jansa [martin.ja...@gmail.com] Sent: Tuesday, April 25, 2017 11:36 AM To: Bystricky, Juro Cc: Patches and discussions about the oe-core layer; jurobystri...@hotmail.com Subject: Re: [OE-core] [PATCH 0/4] Reproducible binaries
Is using the last commit really that useful? I would like to be able to compare 2 subsequent builds (ideally performed on 2 different hosts with some small modification in metadata layers) and the binaries not affected by those small metadata modifications should be the same - which is not the case if we feed them with the top commit date. The real world use-case is that we're doing daily official builds (which don't use sstate for some bad reasons) and just comparing files-in-image.txt file from buildhistory shows that almost all binaries are different every day (just their size fluctuating +- 2 bytes from the linker mangling) and when something goes wrong, it's hard to find "the significant diff" when it's always all different even when the 2nd build only had very small change in image recipe. On Tue, Apr 25, 2017 at 8:14 PM, Juro Bystricky <juro.bystri...@intel.com<mailto:juro.bystri...@intel.com>> wrote: This patch set contains several patches aimed to achieve reproducible binaries. Building reproducible binaries may remove certain intentional randomness intended for increased security. Hence, it is reasonable to expect there will be cases where this is not desirable. The user can select his/her preferences via the variable BUILD_REPRODUCIBLE_BINARIES. The variable defaults to "0" (do not build reproducible binaries) in order to minimize any potential regressions. (Once the reproducible binaries code is mature enough, it can be set to "1".) The patch set is rather simple, targeting the "low hanging fruit". For debian packages we get a lot of binary identical packages simply by exporting SOURCE_DATE_EPOCH. For rootfs we get much fewer differences by modified prelinking and by ensuring various timestamps are reproducible. Juro Bystricky (4): bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES base.bbclass: initial support for binary reproducibility image-preling.bbclass: support binary reproducibility rootfs-postcommands.bbclass: support binary reproducibility meta/classes/base.bbclass | 82 ++++++++++++++++++++++++++++++++ meta/classes/image-prelink.bbclass | 9 +++- meta/classes/rootfs-postcommands.bbclass | 18 ++++++- meta/conf/bitbake.conf | 3 ++ 4 files changed, 109 insertions(+), 3 deletions(-) -- 2.7.4 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
