[OE-core] [PATCH 0/4] Reproducible binaries
Martin Jansa
martin.jansa at gmail.com
Wed Apr 26 07:42:12 UTC 2017
On Tue, Apr 25, 2017 at 07:24:08PM +0000, Bystricky, Juro wrote:
> <html dir="ltr">
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
> <style type="text/css" id="owaParaStyle">P {margin-top:0;margin-bottom:0;}</style>
> </head>
> <body fpstyle="1" ocsi="0">
> <div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">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<br>
> 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.<br>
> <div style="font-family: Times New Roman; color: #000000; font-size: 16px">
> <hr tabindex="-1">
> <div id="divRpF588021" style="direction: ltr;"><font size="2" color="#000000" face="Tahoma"><b>From:</b> Martin Jansa [martin.jansa at gmail.com]<br>
> <b>Sent:</b> Tuesday, April 25, 2017 11:36 AM<br>
> <b>To:</b> Bystricky, Juro<br>
> <b>Cc:</b> Patches and discussions about the oe-core layer; jurobystricky at hotmail.com<br>
> <b>Subject:</b> Re: [OE-core] [PATCH 0/4] Reproducible binaries<br>
> </font><br>
> </div>
> <div></div>
> <div>
> <div dir="ltr">Is using the last commit really that useful?
> <div><br>
> </div>
> <div>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.</div>
> <div><br>
> </div>
> <div>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.</div>
> </div>
> <div class="gmail_extra"><br>
> <div class="gmail_quote">On Tue, Apr 25, 2017 at 8:14 PM, Juro Bystricky <span dir="ltr">
> <<a href="mailto:juro.bystricky at intel.com" target="_blank">juro.bystricky at intel.com</a>></span> wrote:<br>
> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
> This patch set contains several patches aimed to achieve reproducible binaries.<br>
> Building reproducible binaries may remove certain intentional<br>
> randomness intended for increased security. Hence, it is reasonable<br>
> to expect there will be cases where this is not desirable.<br>
> The user can select his/her preferences via the variable<br>
> BUILD_REPRODUCIBLE_BINARIES. The variable defaults to "0" (do not<br>
> build reproducible binaries) in order to minimize any potential<br>
> regressions. (Once the reproducible binaries code is mature enough,<br>
> it can be set to "1".)<br>
> <br>
> The patch set is rather simple, targeting the "low hanging fruit".<br>
> For debian packages we get a lot of binary identical packages simply by<br>
> exporting SOURCE_DATE_EPOCH.<br>
> For rootfs we get much fewer differences by modified prelinking and by<br>
> ensuring various timestamps are reproducible.<br>
But not for 2 different builds with slightly modified metadata (e.g.
just because top commit is different in whatever build repository you're
running from even when it doesn't have any effect in your image), right?
So it doesn't fix the files-in-image.txt differences as described in:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5866
> <br>
> <br>
> Juro Bystricky (4):<br>
> bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES<br>
> base.bbclass: initial support for binary reproducibility<br>
> image-preling.bbclass: support binary reproducibility<br>
> rootfs-postcommands.bbclass: support binary reproducibility<br>
> <br>
> meta/classes/base.bbclass | 82 ++++++++++++++++++++++++++++++<wbr>++<br>
> meta/classes/image-prelink.<wbr>bbclass | 9 +++-<br>
> meta/classes/rootfs-<wbr>postcommands.bbclass | 18 ++++++-<br>
> meta/conf/bitbake.conf | 3 ++<br>
> 4 files changed, 109 insertions(+), 3 deletions(-)<br>
> <span class="HOEnZb"><font color="#888888"><br>
> --<br>
> 2.7.4<br>
> <br>
> --<br>
> ______________________________<wbr>_________________<br>
> Openembedded-core mailing list<br>
> <a href="mailto:Openembedded-core at lists.openembedded.org" target="_blank">Openembedded-core at lists.<wbr>openembedded.org</a><br>
> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
> </font></span></blockquote>
> </div>
> <br>
> </div>
> </div>
> </div>
> </div>
> </body>
> </html>
--
Martin 'JaMa' Jansa jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170426/edf2ae3e/attachment-0002.sig>
More information about the Openembedded-core
mailing list