[PATCH 0/4] Reproducible binaries

[PATCH 0/4] Reproducible binaries

[Juro Bystricky]

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

[PATCH 1/4] bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES

[Juro Bystricky]

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".)

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
---
 meta/conf/bitbake.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 227babd..0c1091e 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -859,3 +859,6 @@ BB_SIGNATURE_EXCLUDE_FLAGS ?= "doc deps depends \
 
 MLPREFIX ??= ""
 MULTILIB_VARIANTS ??= ""
+
+BUILD_REPRODUCIBLE_BINARIES ??= "0"
+BUILD_REPRODUCIBLE_BINARIES[export] = "1"
-- 
2.7.4

[PATCH 2/4] base.bbclass: initial support for binary reproducibility

[Juro Bystricky]

Conditionally set some environment variables in order to achieve
improved binary reproducibility. Providing BUILD_REPRODUCIBLE_BINARIES is
set to "1", we set the following environment variables:

export PYTHONHASHSEED=0
export PERL_HASH_SEED=0
export TZ="UTC"

We also export and set SOURCE_DATE_EPOCH. The value for this variable
is obtained after source code for a recipe has been unpacked, but before it is
patched. If the code comes from a GIT repo, we get the timestamp from the top
commit. (This usually corresponds to the mktime of "changelog".)
Otherwise we go through all files and get the timestamp from the youngest
one. We create a timestamp for each recipe. The timestamp is stored in the file
'src_date_epoch.txt'. Later on, each task reads this file and sets SOURCE_DATE_EPOCH
based on the value found in the file.

[YOCTO#11178]
[YOCTO#11179]

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
---
 meta/classes/base.bbclass | 82 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 82 insertions(+)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index e29821f..f2b2d97 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -10,6 +10,52 @@ inherit utility-tasks
 inherit metadata_scm
 inherit logging
 
+def get_git_src_date_epoch(d, path):
+    import subprocess
+    saved_cwd = os.getcwd()
+    os.chdir(path)
+    src_date_epoch = int(subprocess.check_output(['git','log','-1','--pretty=%ct']))
+    os.chdir(saved_cwd)
+    return src_date_epoch
+
+def create_src_date_epoch_stamp(d):
+    if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
+        path = d.getVar('S')
+        src_date_epoch = 0
+        filename_dbg = None
+
+        if path.endswith('/git'):
+            src_date_epoch = get_git_src_date_epoch(d, path)
+        else:
+            exclude = set(["temp", "licenses", "patches", "recipe-sysroot-native", "recipe-sysroot" ])
+            for root, dirs, files in os.walk(path, topdown=True):
+                dirs[:] = [d for d in dirs if d not in exclude]
+                if root.endswith('/git'):
+                    src_date_epoch = get_git_src_date_epoch(d, root)
+                    break
+
+                for fname in files:
+                    filename = os.path.join(root, fname)
+                    try:
+                        mtime = int(os.path.getmtime(filename))
+                    except:
+                        mtime = 0
+                    if mtime > src_date_epoch:
+                        src_date_epoch = mtime
+                        filename_dbg = filename
+
+        # Most likely an empty folder
+        if src_date_epoch == 0:
+            bb.warn("Unable to determine src_date_epoch! path:%s" % path)
+
+        f = open(os.path.join(path,'src_date_epoch.txt'), 'w')
+        f.write(str(src_date_epoch))
+        f.close()
+
+        if filename_dbg != None:
+            bb.debug(1," src_date_epoch %d derived from: %s" % (src_date_epoch, filename_dbg))
+
+
 OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license"
 OE_IMPORTS[type] = "list"
 
@@ -173,6 +219,7 @@ python base_do_unpack() {
     try:
         fetcher = bb.fetch2.Fetch(src_uri, d)
         fetcher.unpack(d.getVar('WORKDIR'))
+        create_src_date_epoch_stamp(d)
     except bb.fetch2.BBFetchException as e:
         bb.fatal(str(e))
 }
@@ -383,9 +430,43 @@ def set_packagetriplet(d):
 
     settriplet(d, "PKGMLTRIPLETS", archs, tos, tvs)
 
+
+export PYTHONHASHSEED
+export PERL_HASH_SEED
+export SOURCE_DATE_EPOCH
+
+BB_HASHBASE_WHITELIST += "SOURCE_DATE_EPOCH PYTHONHASHSEED PERL_HASH_SEED "
+
 python () {
     import string, re
 
+    # Create reproducible_environment
+
+    if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
+        import subprocess
+        d.setVar('PYTHONHASHSEED', '0')
+        d.setVar('PERL_HASH_SEED', '0')
+        d.setVar('TZ', 'UTC')
+
+        path = d.getVar('S')
+        epochfile = os.path.join(path,'src_date_epoch.txt')
+        if os.path.isfile(epochfile):
+            f = open(epochfile, 'r')
+            src_date_epoch = f.read()
+            f.close()
+            bb.debug(1, "src_date_epoch stamp found ---> stamp %s" % src_date_epoch)
+            d.setVar('SOURCE_DATE_EPOCH', src_date_epoch)
+        else:
+            bb.debug(1, "src_date_epoch stamp not found.")
+            d.setVar('SOURCE_DATE_EPOCH', '0')
+    else:
+        if 'PYTHONHASHSEED' in os.environ:
+            del os.environ['PYTHONHASHSEED']
+        if 'PERL_HASH_SEED' in os.environ:
+            del os.environ['PERL_HASH_SEED']
+        if 'SOURCE_DATE_EPOCH' in os.environ:
+            del os.environ['SOURCE_DATE_EPOCH']
+
     # Handle PACKAGECONFIG
     #
     # These take the form:
@@ -678,6 +759,7 @@ python () {
             bb.warn("Recipe %s is marked as only being architecture specific but seems to have machine specific packages?! The recipe may as well mark itself as machine specific directly." % d.getVar("PN"))
 }
 
+
 addtask cleansstate after do_clean
 python do_cleansstate() {
         sstate_clean_cachefiles(d)
-- 
2.7.4

[PATCH 3/4] image-preling.bbclass: support binary reproducibility

[Juro Bystricky]

Conditionally support binary reproducibility in built images.
If BUILD_REPRODUCIBLE_BINARIES = 1 then:

1. Do not randomize library addresses
2. Set/export PRELINK_TIMESTAMP to a reproducible value.
   The value is derived from the top git commit.

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
---
 meta/classes/image-prelink.bbclass | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image-prelink.bbclass b/meta/classes/image-prelink.bbclass
index 4157df0..78ef65a 100644
--- a/meta/classes/image-prelink.bbclass
+++ b/meta/classes/image-prelink.bbclass
@@ -36,7 +36,14 @@ prelink_image () {
 	dynamic_loader=$(linuxloader)
 
 	# prelink!
-	${STAGING_SBINDIR_NATIVE}/prelink --root ${IMAGE_ROOTFS} -amR -N -c ${sysconfdir}/prelink.conf --dynamic-linker $dynamic_loader
+	if [ "$BUILD_REPRODUCIBLE_BINARIES" = "1" ]; then
+		bbnote " prelink: BUILD_REPRODUCIBLE_BINARIES..."
+		# SOURCE_DATE_EPOCH is 0 (no soure files), so get the timestamp from GIT repo...
+		export PRELINK_TIMESTAMP=`git log -1 --pretty=%ct `
+		${STAGING_SBINDIR_NATIVE}/prelink --root ${IMAGE_ROOTFS} -am -N -c ${sysconfdir}/prelink.conf --dynamic-linker $dynamic_loader
+	else
+		${STAGING_SBINDIR_NATIVE}/prelink --root ${IMAGE_ROOTFS} -amR -N -c ${sysconfdir}/prelink.conf --dynamic-linker $dynamic_loader
+	fi
 
 	# Remove the prelink.conf if we had to add it.
 	if [ "$dummy_prelink_conf" = "true" ]; then
-- 
2.7.4

[PATCH 4/4] rootfs-postcommands.bbclass: support binary reproducibility

[Juro Bystricky]

Conditionally support binary reproducibility of rootfs images.
If BUILD_REPRODUCIBLE_BINARIES = 1 then:

1. set /etc/timestamp to a reproducible value
2. set /etc/version to a reproducible value

The value for /etc/version is modified in a designated catch-all
post-rootfs function "rootfs_reproducible". This function is expected
to provide additional functionality to improve the determinism based
on future needs

[YOCTO#11176]

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
---
 meta/classes/rootfs-postcommands.bbclass | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass b/meta/classes/rootfs-postcommands.bbclass
index 498174a..be1e8dd 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -28,6 +28,8 @@ ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", "systemd"
 
 ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 
+ROOTFS_POSTPROCESS_COMMAND += 'rootfs_reproducible;'
+
 # Disable DNS lookups, the SSH_DISABLE_DNS_LOOKUP can be overridden to allow
 # distros to choose not to take this change
 SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
@@ -246,7 +248,12 @@ python write_image_manifest () {
 # Can be use to create /etc/timestamp during image construction to give a reasonably
 # sane default time setting
 rootfs_update_timestamp () {
-	date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
+	if [ "$BUILD_REPRODUCIBLE_BINARIES" = "1" ]; then
+		bbnote " rootfs_update_timestamp: BUILD_REPRODUCIBLE_BINARIES..."
+		git log -1 --pretty=%cd --date=format:%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
+	else
+		date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
+	fi
 }
 
 # Prevent X from being started
@@ -286,7 +293,6 @@ rootfs_sysroot_relativelinks () {
 	sysroot-relativelinks.py ${SDK_OUTPUT}/${SDKTARGETSYSROOT}
 }
 
-
 # Generated test data json file
 python write_image_test_data() {
     from oe.data import export2json
@@ -302,3 +308,11 @@ python write_image_test_data() {
        os.remove(testdata_link)
     os.symlink(os.path.basename(testdata), testdata_link)
 }
+
+# Perform any additional adjustments needed to make rootf binary reproducible
+rootfs_reproducible () {
+	if [ "$BUILD_REPRODUCIBLE_BINARIES" = "1" ]; then
+		bbnote " rootfs_reproducible: set /etc/version..."
+		git log -1 --pretty=%cd --date=format:%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/version
+	fi
+}
-- 
2.7.4

Re: [PATCH 0/4] Reproducible binaries

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

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@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
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 3358 bytes --]

Re: [PATCH 0/4] Reproducible binaries

[Bystricky, Juro]

[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]

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@gmail.com]
Sent: Tuesday, April 25, 2017 11:36 AM
To: Bystricky, Juro
Cc: Patches and discussions about the oe-core layer; jurobystricky@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@intel.com<mailto:juro.bystricky@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


[-- Attachment #2: Type: text/html, Size: 5080 bytes --]

Re: [PATCH 0/4] Reproducible binaries

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5720 bytes --]

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.&nbsp; 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@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@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
>  &#43;- 2 bytes from the linker mangling) and when something goes wrong, it's hard to find &quot;the significant diff&quot; 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">
> &lt;<a href="mailto:juro.bystricky@intel.com" target="_blank">juro.bystricky@intel.com</a>&gt;</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 &quot;0&quot; (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 &quot;1&quot;.)<br>
> <br>
> The patch set is rather simple, targeting the &quot;low hanging fruit&quot;.<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>
> &nbsp; bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES<br>
> &nbsp; base.bbclass: initial support for binary reproducibility<br>
> &nbsp; image-preling.bbclass: support binary reproducibility<br>
> &nbsp; rootfs-postcommands.bbclass: support binary reproducibility<br>
> <br>
> &nbsp;meta/classes/base.bbclass&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | 82 &#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;&#43;<wbr>&#43;&#43;<br>
> &nbsp;meta/classes/image-prelink.<wbr>bbclass&nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; 9 &#43;&#43;&#43;-<br>
> &nbsp;meta/classes/rootfs-<wbr>postcommands.bbclass | 18 &#43;&#43;&#43;&#43;&#43;&#43;-<br>
> &nbsp;meta/conf/bitbake.conf&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; 3 &#43;&#43;<br>
> &nbsp;4 files changed, 109 insertions(&#43;), 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@lists.openembedded.org" target="_blank">Openembedded-core@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@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [PATCH 0/4] Reproducible binaries

[Bystricky, Juro]

> 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?
> 

This may be addressed in the future. Presently, the goal is to ensure that if we
use identical repositories we get identical results. This should not depend
on the time/date, build folder or even Linux distro. By identical results
I mean binary identical comparison of the resulting "deploy" folders.
(images, packages, licenses). So for example, there should be no binary differences 
between the two images of core-image-minimal.rootfs.ext4.
In your case (slightly different repos), the difference would be presented 
as different time stamps for /etc/version and /etc/timestamp only.


> So it doesn't fix the files-in-image.txt differences as described in:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5866
> 

Eventually it will. There is still ways to go and this patch set is just the first
kick at the can.

Re: [PATCH 0/4] Reproducible binaries

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

What about passing the seed value (currently created based on last commit
in repo you're building from - which doesn't need to be oe-core repository
right?) to make it easier for people to pass whatever value works for them?
even some constant value in DISTRO config.

On Wed, Apr 26, 2017 at 6:43 PM, Bystricky, Juro <juro.bystricky@intel.com>
wrote:

>
> > 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?
> >
>
> This may be addressed in the future. Presently, the goal is to ensure that
> if we
> use identical repositories we get identical results. This should not depend
> on the time/date, build folder or even Linux distro. By identical results
> I mean binary identical comparison of the resulting "deploy" folders.
> (images, packages, licenses). So for example, there should be no binary
> differences
> between the two images of core-image-minimal.rootfs.ext4.
> In your case (slightly different repos), the difference would be presented
> as different time stamps for /etc/version and /etc/timestamp only.
>
>
> > So it doesn't fix the files-in-image.txt differences as described in:
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=5866
> >
>
> Eventually it will. There is still ways to go and this patch set is just
> the first
> kick at the can.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2025 bytes --]

Re: [PATCH 0/4] Reproducible binaries

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]

That sounds better option but we still will need a fallback there is a
libfakedatetime as well which can be used to generate consistent date and
time

On Wed, Apr 26, 2017 at 10:52 AM Martin Jansa <martin.jansa@gmail.com>
wrote:

> What about passing the seed value (currently created based on last commit
> in repo you're building from - which doesn't need to be oe-core repository
> right?) to make it easier for people to pass whatever value works for them?
> even some constant value in DISTRO config.
>
> On Wed, Apr 26, 2017 at 6:43 PM, Bystricky, Juro <juro.bystricky@intel.com
> > wrote:
>
>>
>> > 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?
>> >
>>
>> This may be addressed in the future. Presently, the goal is to ensure
>> that if we
>> use identical repositories we get identical results. This should not
>> depend
>> on the time/date, build folder or even Linux distro. By identical results
>> I mean binary identical comparison of the resulting "deploy" folders.
>> (images, packages, licenses). So for example, there should be no binary
>> differences
>> between the two images of core-image-minimal.rootfs.ext4.
>> In your case (slightly different repos), the difference would be presented
>> as different time stamps for /etc/version and /etc/timestamp only.
>>
>>
>> > So it doesn't fix the files-in-image.txt differences as described in:
>> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=5866
>> >
>>
>> Eventually it will. There is still ways to go and this patch set is just
>> the first
>> kick at the can.
>>
>>
>>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2847 bytes --]

Re: [PATCH 0/4] Reproducible binaries

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

On Wed, Apr 26, 2017 at 07:52:02PM +0200, Martin Jansa wrote:
> What about passing the seed value (currently created based on last commit
> in repo you're building from - which doesn't need to be oe-core repository
> right?) to make it easier for people to pass whatever value works for them?
> even some constant value in DISTRO config.

It looks like some words disappeared when I clicked the send button.
Well I don't have any buttons in mutt so that might be the reason.

I wasnted to say "passing the seed value" through some separate variable
which is easy to override from somewhere else.

e.g.
export PRELINK_TIMESTAMP=`git log -1 --pretty=%ct `

in image-prelink.bbclass:prelink_image() is a bit difficult to override.

> 
> On Wed, Apr 26, 2017 at 6:43 PM, Bystricky, Juro <juro.bystricky@intel.com>
> wrote:
> 
> >
> > > 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?
> > >
> >
> > This may be addressed in the future. Presently, the goal is to ensure that
> > if we
> > use identical repositories we get identical results. This should not depend
> > on the time/date, build folder or even Linux distro. By identical results
> > I mean binary identical comparison of the resulting "deploy" folders.
> > (images, packages, licenses). So for example, there should be no binary
> > differences
> > between the two images of core-image-minimal.rootfs.ext4.
> > In your case (slightly different repos), the difference would be presented
> > as different time stamps for /etc/version and /etc/timestamp only.
> >
> >
> > > So it doesn't fix the files-in-image.txt differences as described in:
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=5866
> > >
> >
> > Eventually it will. There is still ways to go and this patch set is just
> > the first
> > kick at the can.
> >
> >
> >

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [PATCH 0/4] Reproducible binaries

[Bystricky, Juro]

> I wasnted to say "passing the seed value" through some separate variable
> which is easy to override from somewhere else.
> 
> e.g.
> export PRELINK_TIMESTAMP=`git log -1 --pretty=%ct `
> 
> in image-prelink.bbclass:prelink_image() is a bit difficult to override.
> 

I think it is best to keep all reproducible build related variables gathered together, 
so bitbake.conf seems like a natural place (same place as the variable BUILD_REPRODUCIBLE_BINARIES),
i.e something like:

PRELINK_TIMESTAMP ??=`git log -1 --pretty=%ct `

A single "general purpose" fallback timestamp variable (not specific to prelinking) would be my
preference. Unfortunately, the timestamps may need to come in various different formats...

Re: [PATCH 0/4] Reproducible binaries

[Joshua Lock]

On Wed, 2017-04-26 at 19:50 +0000, Bystricky, Juro wrote:
> > I wasnted to say "passing the seed value" through some separate
> > variable
> > which is easy to override from somewhere else.
> > 
> > e.g.
> > export PRELINK_TIMESTAMP=`git log -1 --pretty=%ct `
> > 
> > in image-prelink.bbclass:prelink_image() is a bit difficult to
> > override.
> > 
> 
> I think it is best to keep all reproducible build related variables
> gathered together, 
> so bitbake.conf seems like a natural place (same place as the
> variable BUILD_REPRODUCIBLE_BINARIES),
> i.e something like:
> 
> PRELINK_TIMESTAMP ??=`git log -1 --pretty=%ct `
> 
> A single "general purpose" fallback timestamp variable (not specific
> to prelinking) would be my
> preference. Unfortunately, the timestamps may need to come in various
> different formats...

One option for a single general purpose timestamp variable is just to
use a static value. Guix[1] just set the value of SOURCE_DATE_EPOCH to
1[2].

Joshua

1. https://www.gnu.org/software/guix/
2. http://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/gnu-build-
system.scm#n42

Re: [PATCH 0/4] Reproducible binaries

[Bystricky, Juro]

SOURCE_DATE_EPOCH is not the issue here. There are few other places that require timestamps.
SOURCE_DATE_EPOCH is determined as the mktime of the youngest source file or if git repo present
as the time of the top commit. (Otherwise it defaults to 0). This needs to be done per package.
I'll send in a new set of patches, with additional timestamps related variables that will allow user customization.



________________________________________
From: Joshua Lock [joshua.g.lock@linux.intel.com]
Sent: Thursday, April 27, 2017 2:50 AM
To: Bystricky, Juro; Martin Jansa
Cc: jurobystricky@hotmail.com; Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 0/4] Reproducible binaries

On Wed, 2017-04-26 at 19:50 +0000, Bystricky, Juro wrote:
> > I wasnted to say "passing the seed value" through some separate
> > variable
> > which is easy to override from somewhere else.
> >
> > e.g.
> > export PRELINK_TIMESTAMP=`git log -1 --pretty=%ct `
> >
> > in image-prelink.bbclass:prelink_image() is a bit difficult to
> > override.
> >
>
> I think it is best to keep all reproducible build related variables
> gathered together,
> so bitbake.conf seems like a natural place (same place as the
> variable BUILD_REPRODUCIBLE_BINARIES),
> i.e something like:
>
> PRELINK_TIMESTAMP ??=`git log -1 --pretty=%ct `
>
> A single "general purpose" fallback timestamp variable (not specific
> to prelinking) would be my
> preference. Unfortunately, the timestamps may need to come in various
> different formats...

One option for a single general purpose timestamp variable is just to
use a static value. Guix[1] just set the value of SOURCE_DATE_EPOCH to
1[2].

Joshua

1. https://www.gnu.org/software/guix/
2. http://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/gnu-build-
system.scm#n42

Re: [PATCH 0/4] Reproducible binaries

[Trevor Woerner]

On Tue, Apr 25, 2017 at 2:14 PM, Juro Bystricky
<juro.bystricky@intel.com> wrote:
> 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".)

My guess is that people would prefer security over reproducibility.
Maybe we need more consensus for the default value going forward?

Re: [PATCH 0/4] Reproducible binaries

[Patrick Ohly]

On Tue, 2017-04-25 at 19:22 -0400, Trevor Woerner wrote:
> On Tue, Apr 25, 2017 at 2:14 PM, Juro Bystricky
> <juro.bystricky@intel.com> wrote:
> > 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".)
> 
> My guess is that people would prefer security over reproducibility.

When all machines targeted by an attack run the same build, they also
share the same seeds, regardless whether that build was reproducible or
not. In that case it doesn't matter, the attack method and complexity
would be the same with or without reproducibility.

It gets a bit harder when targeting multiple different OS builds, but
relying on randomness in the build as a defense against attacks isn't
particularly secure.

If people prefer security, they shouldn't use prelinking and ensure that
the machines comes up with good, per-machine entropy for the random
number generation that needs to happen on the machine.

How much does reproducibility then still matter? I suspect not that
much.

> Maybe we need more consensus for the default value going forward?

Yes, it's worth considering.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [PATCH 0/4] Reproducible binaries

[Bystricky, Juro]

Consensus is always a good thing.
The user can override the default by explicitly specifying (for example in local.conf)
BUILD_REPRODUCIBLE_BINARIES="1"
or
BUILD_REPRODUCIBLE_BINARIES="0"

> -----Original Message-----
> From: Trevor Woerner [mailto:twoerner@gmail.com]
> Sent: Tuesday, April 25, 2017 4:22 PM
> To: Bystricky, Juro <juro.bystricky@intel.com>
> Cc: Patches and discussions about the oe-core layer <openembedded-
> core@lists.openembedded.org>; jurobystricky@hotmail.com
> Subject: Re: [OE-core] [PATCH 0/4] Reproducible binaries
> 
> On Tue, Apr 25, 2017 at 2:14 PM, Juro Bystricky
> <juro.bystricky@intel.com> wrote:
> > 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".)
> 
> My guess is that people would prefer security over reproducibility.
> Maybe we need more consensus for the default value going forward?