Re: [OE-core] [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.l...@linux.intel.com]
Sent: Thursday, April 27, 2017 2:50 AM
To: Bystricky, Juro; Martin Jansa
Cc: jurobystri...@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 +, 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Joshua Lock]

On Wed, 2017-04-26 at 19:50 +, 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [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...

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Martin Jansa]

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 
> 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.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Khem Raj]

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

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

[Martin Jansa]

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

Re: [OE-core] [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.


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [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:twoer...@gmail.com]
> Sent: Tuesday, April 25, 2017 4:22 PM
> To: Bystricky, Juro <juro.bystri...@intel.com>
> Cc: Patches and discussions about the oe-core layer  c...@lists.openembedded.org>; jurobystri...@hotmail.com
> Subject: Re: [OE-core] [PATCH 0/4] Reproducible binaries
> 
> On Tue, Apr 25, 2017 at 2:14 PM, Juro Bystricky
> <juro.bystri...@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?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Martin Jansa]

On Tue, Apr 25, 2017 at 07:24:08PM +, Bystricky, Juro wrote:
> 
> 
> 
> P 
> {margin-top:0;margin-bottom:0;}
> 
> 
> 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.
> 
> 
>  face="Tahoma">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 
> 
> mailto:juro.bystri...@intel.com; 
> target="_blank">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.

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

> 
> 
> 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
> mailto:Openembedded-core@lists.openembedded.org; 
> target="_blank">Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core; 
> rel="noreferrer" 
> target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> 
> 
> 
> 
> 
> 
> 

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


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [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
>  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.



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Trevor Woerner]

On Tue, Apr 25, 2017 at 2:14 PM, Juro Bystricky
 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?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [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.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

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

[Martin Jansa]

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

[OE-core] [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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core