...@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
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
> 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
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?
>
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
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
> 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
> 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, A
yway, 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;
> jurob
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
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
: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
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
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
14 matches
Mail list logo