Re: Bug#844431: Reproducibility in Policy

[Bill Allombert]

On Fri, Aug 11, 2017 at 04:08:47PM -0700, Sean Whitton wrote:
> control: user debian-pol...@packages.debian.org
> control: usertag = normative proposal
> 
> Hello,
> 
>  Proposal: 
> 
> This is what Holger and I think we should add to Policy, after
> readability tweaks:
> 
> Packages should build reproducibly, which for purposes of this
> document means that given
> 
> - a version of a source package unpacked at a given path;
> - a set of versions of installed build-dependencies; and
> - a build architecture,
> 
> repeatedly building the source package on the architecture with those
> versions of the build dependencies installed will produce bit-for-bit
> identical binary packages.
> 
>  Explanation: 
> 
> The definition from the reproducible builds group[1] says:
> 
> A build is reproducible if given the same source code, build
> environment and build instructions, any party can recreate
> bit-by-bit identical copies of all specified artifacts.
> 
> The relevant attributes of the build environment, the build
> instructions and the source code as well as the expected
> reproducible artifacts are defined by ... distributors.
> 
> i.e. Debian has to define the build environment, source code and build
> instructions.  I think that my wording defines these as Debian currently
> understands them.

This require policy to define the build environment and build
instruction much more precisely than it does now, which does not
seems to be practical. Unless maybe if a reference implementation
is provided.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: Bug#844431: Reproducibility in Policy

[Johannes Schauer]

Hi,

Quoting Russ Allbery (2017-08-12 09:57:44)
> I think we need to add all environment variables starting with DEB_* to
> the prerequisites.  If you set DEB_BUILD_OPTIONS=nostrip or
> DEB_BUILD_MAINT_OPTIONS=hardening=all, you'll definitely get a different
> package, for instance.
> 
> I feel like there are a bunch of other environment variables that have to
> be consistent, although I'm not sure how to specify that since other
> environment variables shouldn't matter.  But, say, setting GNUTARGET is
> very likely to cause weirdness by changing how ld works.  There are
> probably more interesting examples.
> 
> How does the current reproducible build testing work with the environment?
> Maybe we should just document that for right now and relax it later if
> needed?

currently, dpkg-genbuildinfo records all environment variables in a .buildinfo
file which pass a whitelist check. The current whitelist is stored here:

https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Build/Info.pm#n50

I'm not proposing that this whole list should be added to policy. But the list
that ends up in policy must be a subset of the list of environment variables
that dpkg-genbuildinfo stores in the .buildinfo file. Thus:

 - this list from dpkg should give a number of good suggestions of which
   environment variables should be added to policy

 - if any additional variables are added, then they must be added to
   dpkg-genbuildinfo as well.

Thanks!

cheers, josch


signature.asc
Description: signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: Bug#844431: Reproducibility in Policy

[Russ Allbery]

Daniel Kahn Gillmor  writes:
> On Fri 2017-08-11 16:08:47 -0700, Sean Whitton wrote:

>> - a version of a source package unpacked at a given path;

> I don't like the idea of hard-coding a fixed build path requirement into
> debian policy.  We're over 80% with variable build paths in unstable
> already, and i want to keep the pressure up on this.  The build location
> should not influence the binary output.

It shouldn't, but my understanding is that it currently does.  If you can
fix that, that's great, but until that's been fixed, I don't see the harm
in documenting this as a prerequisite for a reproducible build.  If we can
relax that prerequisite later, great, but nothing about listing it here
should reduce the pressure on making variable build paths work.  It just
documents the current state of the world.

-- 
Russ Allbery (r...@debian.org)   

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: Bug#844431: Reproducibility in Policy

[Russ Allbery]

Sean Whitton  writes:

>  Proposal: 

> This is what Holger and I think we should add to Policy, after
> readability tweaks:

> Packages should build reproducibly, which for purposes of this
> document means that given

> - a version of a source package unpacked at a given path;
> - a set of versions of installed build-dependencies; and
> - a build architecture,

> repeatedly building the source package on the architecture with those
> versions of the build dependencies installed will produce bit-for-bit
> identical binary packages.

I think we need to add all environment variables starting with DEB_* to
the prerequisites.  If you set DEB_BUILD_OPTIONS=nostrip or
DEB_BUILD_MAINT_OPTIONS=hardening=all, you'll definitely get a different
package, for instance.

I feel like there are a bunch of other environment variables that have to
be consistent, although I'm not sure how to specify that since other
environment variables shouldn't matter.  But, say, setting GNUTARGET is
very likely to cause weirdness by changing how ld works.  There are
probably more interesting examples.

How does the current reproducible build testing work with the environment?
Maybe we should just document that for right now and relax it later if
needed?

>  Explanation: 

> The definition from the reproducible builds group[1] says:

> A build is reproducible if given the same source code, build
> environment and build instructions, any party can recreate
> bit-by-bit identical copies of all specified artifacts.

> The relevant attributes of the build environment, the build
> instructions and the source code as well as the expected
> reproducible artifacts are defined by ... distributors.

> i.e. Debian has to define the build environment, source code and build
> instructions.  I think that my wording defines these as Debian currently
> understands them.

> Later, we could narrow the definition of build environment by adding
> more constraints, but we're not there yet.

> [1]  https://reproducible-builds.org/docs/definition/

We should add a link to that page (maybe in a footnote).

-- 
Russ Allbery (r...@debian.org)   

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds