Bug#844431: Packages should be reproducible
On 17-08-17 14:38:38, Edroman wrote: > Regarding to reproducible, I would suggest Debian should consider > integrating Nix[0] into Debian; as Nix's website mentions > > Nix builds packages in isolation from each other. This ensures that > they are reproducible and don’t have undeclared dependencies, so if a > package works on one machine, it will also work on another. I doubt that building packages in isolation from each other makes them reproducible, especially in the context which is discussed in this bug. Cheers, Georg signature.asc Description: Digital signature
Bug#844431: Packages should be reproducible
Regarding to reproducible, I would suggest Debian should consider integrating Nix[0] into Debian; as Nix's website mentions Nix builds packages in isolation from each other. This ensures that they are reproducible and don’t have undeclared dependencies, so if a package works on one machine, it will also work on another. [0]. https://nixos.org/nix/
Bug#844431: Packages should be reproducible
Chris Lamb wrote on Thu, Nov 17, 2016 at 12:30:44 +0100: > +++ b/policy.sgml > @@ -2503,6 +2503,20 @@ endif > + Note that the id should be changed before applying, since there already is a sect with this id value.
Bug#844431: Packages should be reproducible
Henrique de Moraes Holschuh wrote: > I don't think there will be much of a contention about this. Great :) > Please propose wording (i.e. the diff to the policy text), but > I recommend that you do *not* use "should" or "must" to make such > reproducibility mandatory right now. Completely agreed. Any requirement would be counter-productive and ultimately premature at this stage. I've attached an initial wording to get us going. I'm not 100% convinced with it myself but it should help start any discussion in this area. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff --git a/policy.sgml b/policy.sgml index ee1e9f4..fd7c3d7 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2503,6 +2503,20 @@ endif multiple times to generate different binary packages). + + + Reproducibility + + + It is recommended that packages build in a reproducible manner, ie. + bit-for-bit identical binaries are always generated from a given + source. + + + + In the future, this will become a requirement. + +
Bug#844431: Packages should be reproducible
On Tue, 15 Nov 2016, Chris Lamb wrote: > [As a mild suggestion to streamline this; we should probably come to some > consensus on principle of this addition to Policy first and only then > move to the more difficult topic of defining exactly what reproducibility > means in a technical sense.] I don't think there will be much of a contention about this. Please propose wording (i.e. the diff to the policy text), but I recommend that you do *not* use "should" or "must" to make such reproducibility mandatory right now, only to define stuff like "*if* it is built for reproducibility, it must do so in such a way that...", etc. Enforcing package reproducibility (should/must in policy) has to wait until a majority of the package is effectively being reproducibly built for a small while (to shaken up any issues), and the tooling echosystem is complete so that it is actually usable to verify things. IMHO, this would be best done only after stretch is released, even if we reach >85% reproducibility levels *and* a full, working toolset before that. As a suggestion, since a "may build reproducibly" policy is not going to give the readers the desired idea, the policy text proposal could use words to the effect that "it is recommended that", and "in the future, this will become a requirement". Any packages that absolutely cannot be built in a reproducible way[1], can become oficially allowed exceptions -- and we could likely teach the verification tools that specific regions of a package/file are to be random, and ignore those when comparing for reproducibility, too. But this would be tackled on in the future, between an already implemented policy of SHOULD is out, and >95% of the packages are being built reproducibly and policy is about to be changed to MUST. Therefore, the initial proposal just needs to acknowledge that this fact could happen and will be dealt with in time. [1] Such as random noise added to kernel and firmware data structures during local builds, to be used as a last defense to avoid the *herd using same keys* effects, etc. -- Henrique Holschuh
Bug#844431: Packages should be reproducible
Package: debian-policy Version: 3.9.8.0 X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Policy maintainers, Whilst anyone can inspect the source code in Debian for malicious flaws, we distribute pre-compiled to end users. The motivation behind the Reproducible Builds effort is to permit verification that no flaws have been introduced — either maliciously or accidentally — during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. Debian has been making great strides to make itself reproducible, contributing 100s patches, not only within Debian itself but also to upstream projects. We have also been running a comprehensive and non- trivial CI framework to test for reproducibility of packages for quite some time. However, the recent arrival of the final pieces of the toolchain into unstable encourages me to propose that we add a recommendation that packages in Debian should be reproducible. This would be act both as documentation of a modern best practice, but also act as a "placeholder" so that we can increase its severity at some future date. [As a mild suggestion to streamline this; we should probably come to some consensus on principle of this addition to Policy first and only then move to the more difficult topic of defining exactly what reproducibility means in a technical sense.] Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
