All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bystricky, Juro" <juro.bystricky@intel.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Cc: "jurobystricky@hotmail.com" <jurobystricky@hotmail.com>
Subject: Re: [PATCH v2 1/6] bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES
Date: Tue, 2 May 2017 00:35:35 +0000	[thread overview]
Message-ID: <6E51916E4A1F32428260031F4C7CD2B611950590@ORSMSX112.amr.corp.intel.com> (raw)
In-Reply-To: <1493680397.23535.47.camel@linuxfoundation.org>

I see your point. The original idea was to keep all related variables in one place. There is 
one variable ( BUILD_REPRODUCIBLE_BINARIES ) that I think should be global,
as it should be visible by all tasks (well, a lot of tasks). The rest can be moved to more appropriate places.


________________________________________
From: Richard Purdie [richard.purdie@linuxfoundation.org]
Sent: Monday, May 01, 2017 4:13 PM
To: Bystricky, Juro; openembedded-core@lists.openembedded.org
Cc: joshua.g.lock@linux.intel.com; Burton, Ross; martin.jansa@gmail.com; raj.khem@gmail.com; jurobystricky@hotmail.com
Subject: Re: [PATCH v2 1/6] bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES

On Mon, 2017-05-01 at 13:58 -0700, Juro Bystricky wrote:
> 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".)
> If the variable BUILD_REPRODUCIBLE_BINARIES is set to "1",
> timestamp values taken from additional variables will be optionally
> used
> when building binary reproducible images:
>
>     REPRODUCIBLE_TIMESTAMP_ROOTFS
>         If the value is specified, all files mtime will be set to
> this value.
>         In addition, /etc/timestamp and /etc/version will both
> contain the value.
>         If no value is specified, timestamp will be derived from the
> top git commit.
>
>     REPRODUCIBLE_TIMESTAMP_IMAGE_PRELINK
>         Value passed via environment variable PRELINK_TIMESTAMP to
> the prelink program.
>         If the value is specified, the value will be used.
>         If no value is specified, timestamp will be derived from the
> top git commit.
>
> Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
> ---
>  meta/conf/bitbake.conf | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 227babd..6ce1a1a 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -859,3 +859,14 @@ BB_SIGNATURE_EXCLUDE_FLAGS ?= "doc deps depends
> \
>
>  MLPREFIX ??= ""
>  MULTILIB_VARIANTS ??= ""
> +
> +BUILD_REPRODUCIBLE_BINARIES ??= "0"
> +BUILD_REPRODUCIBLE_BINARIES[export] = "1"
> +
> +# Unix timestamp
> +REPRODUCIBLE_TIMESTAMP_ROOTFS ??= ""
> +REPRODUCIBLE_TIMESTAMP_ROOTFS[export] = "1"
> +
> +# Unix timestamp
> +REPRODUCIBLE_TIMESTAMP_IMAGE_PRELINK ??= ""
> +REPRODUCIBLE_TIMESTAMP_IMAGE_PRELINK[export] = "1"

Please don't add new global exports in bitbake.conf. Changing the value
of this will cause everything to rebuild (e.g. recompile) since the
exported environment goes to all tasks. We really don't want to do that
if it only affects the image generation.

I'll give this a bit more thought/review but wanted to comment on this
whilst I see it/remember.

Cheers,

Richard



  reply	other threads:[~2017-05-02  0:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-01 20:58 [PATCH v2 0/6] Reproducible binaries Juro Bystricky
2017-05-01 20:58 ` [PATCH v2 1/6] bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES Juro Bystricky
2017-05-01 23:13   ` Richard Purdie
2017-05-02  0:35     ` Bystricky, Juro [this message]
2017-05-02  5:55       ` Martin Jansa
2017-05-01 20:59 ` [PATCH v2 2/6] base.bbclass: initial support for binary reproducibility Juro Bystricky
2017-06-14 20:30   ` Martin Jansa
2017-06-14 20:50     ` Bystricky, Juro
2017-05-01 20:59 ` [PATCH v2 3/6] image-prelink.bbclass: support " Juro Bystricky
2017-05-01 20:59 ` [PATCH v2 4/6] rootfs-postcommands.bbclass: " Juro Bystricky
2017-05-01 20:59 ` [PATCH v2 5/6] busybox.inc: improve reproducibility Juro Bystricky
2017-05-02  0:31   ` Andre McCurdy
2017-05-01 20:59 ` [PATCH v2 6/6] image.bbclass: support binary reproducibility Juro Bystricky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6E51916E4A1F32428260031F4C7CD2B611950590@ORSMSX112.amr.corp.intel.com \
    --to=juro.bystricky@intel.com \
    --cc=jurobystricky@hotmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.