Mailinglist Archive: opensuse-packaging (106 mails)

< Previous Next >
Re: [opensuse-packaging] reproducible builds
  • From: Ludwig Nussel <ludwig.nussel@xxxxxxx>
  • Date: Thu, 17 Dec 2015 16:03:42 +0100
  • Message-id: <5672CECE.4080805@suse.de>
Jérémy Bobbio wrote:
Ludwig Nussel:
Michael Matz wrote:
On Fri, 11 Dec 2015, Adam Spiers wrote:

Is anyone working on (or thinking of working on) making our build
process reproducible?

https://reproducible-builds.org/

We have that since about forever as far as easily possible. The hard part
is changing packages to not depend on things like build time (e.g.
encoding build date/time into strings into executables). That's not
something you can do generally in a build system, but must be changed in
each and every individual package.

It's probably worth to explain the difference between our reproducible
builds and this new interpretation. SUSE and openSUSE distributions
have always had reproducible builds, for something like 20 years now.
Reproducible in the sense that a packager never builds binaries on his
own system in some magic way and then uploads binaries.
[…]

Thanks Ludwig for your explanations as we unfortunately use some common
words to convey different ideas.

Exactly. The Maximum RPM book already advertised "Reproducible Builds" in
1997 without promising bit identical results :-)

I want to try to elaborate on them so
we can better colaborate between projects as we—in Tor, Debian and many
other projects—strongly believe that these issues concern all free
software projects.

I believe we have trouble understanding one another because, from my
understanding, we have been working on solving different problems:

The problem openSUSE has solved with OBS is “Can a software be rebuilt
from source?”

Yes, we take that for granted.

[...]
But end users might want to verify by themselves that binaries match a
source code they can audit. When a build process doesn't produce
bit-for-bit identical results, this become much harder.

No doubt about that.

Speaking of build-compare, the tool that we built to debug differences
between two builds, diffoscope, is getting wider exposure and becoming
quite versatile. It's in Python and designed to be as modular as
possible. The hope was to have something more maintainable and
extensible than a single shell script.

One feature diffoscope is missing to become a proper alternative to
build-compare is the ability to filter differences. It's on my list of
things to implement, and I'll eventually get to it, but contributions
would be great if anyone is interested.

To be usable within build roots it would have to be sufficiently
standalone though. Due to the automatic boot strapping and always fresh
build roots we have to be careful to avoid polluting build environments
and causing build cycles.

cu
Ludwig

--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >