[OE-core] [PATCH 0/4] Reproducible binaries

[Bystricky, Juro]

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.jansa at gmail.com]
Sent: Tuesday, April 25, 2017 11:36 AM
To: Bystricky, Juro
Cc: Patches and discussions about the oe-core layer; jurobystricky at 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.bystricky at intel.com<mailto:juro.bystricky at 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 at lists.openembedded.org<mailto:Openembedded-core at lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170425/9d185391/attachment-0002.html>